[Open-graphics] Jumper count to disconnect DDC from DVI connector

[mykrowatt at comcast.net]

   You could do it that way.  Implementations that involve ASIC changes are up to you -- I will always try to offer options that don't require any.
   In that case, plugging in the DDC tool through the back panel or direct to the board would override the DDC port on the DVI connector, rather than spoof it.

   On a related subject, I thought a little more about the SPI EEPROM tool.  I think we don't want it to be able to write to on-board EEPROM unless the user takes positive action to enable it.  It shouldn't get that kind of control just by being plugged in.
   Presumably the ASIC uses NOT CS0 to select the on-board EEPROM, and that signal isn't brought out to the tool connector.  If the user plugs in a jumper to bridge NOT CS2 to NOT CS0, the tool could drive the on-board EEPROM through NOT CS2.
   There are several ways the ASIC could respond to seeing NOT CS2 bridged to NOT CS0.  The simplest thing to do would be not to drive any select lines and leave control with the tool.  The board wouldn't boot, until the tool was through controlling the SPI port, and the jumper was removed.  The next option would be for the ASIC to drive NOT CS1 and boot from external EEPROM, if one is present.
   Again, there are other ways the SPI tool could be manually enabled to write to on-board EEPROM; I'm just looking for least-impact solutions.


 -------------- Original message ----------------------
From: "Timothy Miller" <theosib at gmail.com>
> On 9/7/06, Dieter <netbsd at sopwith.solgatos.com> wrote:
> > >    To answer an earlier question: if we want to include a feature on OGC1 to 
> disconnect the DDC signals from the DVI conne
> > >ctor so that the external tool will have control of those signals, only two 
> lines need to be disconnected: SCL and SDA.  So
> > > the cost impact of doing it with jumper plugs would be minimal.
> >
> > If Jack's design is used, (and if I understand it correctly) I think we
> > could look for a signal on the aux DDC, and if one is found then use it,
> > If no signal is found on the aux DDC, then look for a signal on the
> > DVI's DCC pins.  If this scheme works, then we don't need jumpers for DDC.
> 
> That is an interesting thought.  Just provide secondary DDC signals
> that we probe first.  Adding extra pins is always a concern, however,
> because signals from BGAs are hard to route.  Were it not for the
> density of pins on the 3S4000, OGD1 could have fewer layers.  In fact,
> we have inaccessible pins due to the fact that we don't have enough
> layers to route to the inner-most balls.  I would not begrudge 4 extra
> pins, however, so it's something we'll consider.  Indeed, we may find
> it easy to add the pins but find them too costly to route to.  If we
> add them at all, we'll add them to the inner-most set of balls on
> TRV10.
> _______________________________________________
> Open-graphics mailing list
> Open-graphics at duskglow.com
> http://lists.duskglow.com/mailman/listinfo/open-graphics
> List service provided by Duskglow Consulting, LLC (www.duskglow.com)