-------------- Original message ---------------------- From: "Timothy Miller" <[EMAIL PROTECTED]> > On 8/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > 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. > > Ok. We'll put it in. And it most DEFINITELY needs to go into the > test code for OGD1 (although we'll just hook it to general I/O pins or > headers already on the board). > > Just to be clear, however, I'm not going to go up a die size for this > feature. This will be on a list of optional features. If we find > outselves in a situation where we're using 104% of the die, then this > feature, along with a number of others, will be voted on, one at a > time, for removal until the design fits and performs correctly.
This strikes me as a sound policy. > > > just reading a little further out the SPI chain and looking for a preamble > byte that introduces > > Do you mean SPI or JTAG or I2C? I mean SPI. You might come up with a better choice, but my reasoning is that SPI is simpler to improvise tools for in the field, and easier to understand raw bit streams on a scope. Also, the production TRV10 may or may not have JTAG, but I believe you've already decided that it will have SPI in order to make use of a flash EEPROM. To present a concrete concept for further discussion, suppose that the assigned header pins put the external SPI device on the same clock and data pins as the on-board EEPROM, but have a separate chip select pin. A pullup resistor is provided on MISO to force all-1s if the TRV10 reads from a nonexistent device; that is, it selects the device and sends the SCLK pulses to read a byte from it, but nothing drives the data input. Then it will see FF as the read data, and know that there is no device connected. So it loads the standard power-up mode stored in EEPROM. Now suppose that some SPI device on an external board is plugged into the header. It might be a serial EEPROM programmed by some lab tool, it might be a plain shift register connected to a bank of DIP switches or jumper headers, or it might be a more sophisticated test tool with a microcontroller in it. Regardless, it responds when selected the same way a serial EEPROM would, and drives the data input to the TRV10. Next, let's suppose that if the first byte the external device sends when selected is 5A, it means that the next 15 bytes contain a video mode in the correct raw binary format to be directly loaded into the OGA hardware registers. That's what I mean by providing the very minimum possible hook for initializing an arbitrary video mode without host processor intervention; all the logic complexity is the responsibility of the system integrator or end user when setting the mode bits on the external tool. The only thing the ASIC does is read in bits if they exist, and copy them into the mode registers. OGP doesn't necessarily have to design the external tools; just specify how they have to respond to SPI signals. I'm not going to suggest other header byte values for OGA debugger functions. There are people on the project more qualified than me to think about that. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
