> >>> So, chances are, there are some provisions on the board already to
> >>> flash the devices "in circuit" with or without the aid of the
> >>> processor.
> >> ISTR someone saying that the existing code _is_ willing to reflash
> >> it, provided the new code is suitably signed.
> > Yes.
>
> ...which obviously implies that the electronics on the board are
> capable of it. :-)

Of course -- FROM THE CPU PINS.  But, unless the CPU is
socketed *or* you can convince it to execute code that will
program the Flash (hence the previous discussion), that doesn't
help much.  You want to find a "back door" to access the
pins on the Flash without requiring the CPU's cooperation.

> > But the signature is the pisser.  I am suggesting that the "existing
> > code" had to get in the Flash *somehow*.
>
> True.  The first way that comes to mind is that Sun flashed all the
> flashes with a small "grappling hook" image during manufacturing, one
> that didn't check much and was willing to flash anything, then before
> shipping used that to reflash it with the customer-ship software.

Possible.  Note that if the Flash gets mangled during an upgrade
("return to factory for service"), Sun wants an easy/painless way to fix
this, as well -- ideally without depopulating the PCB, etc.

So, I still stand by the assumption that there is a "manufacturing test"
provision to access/program the Flash... finding it is the trick!

> > And, I am further suggesting that it got in there *after* the device
> > was mated to the PCB (i.e. not preprogrammed by the vendor prior to
> > assembly).  So, poking around might give some insight. (e.g., a
> > conspicuous jumper labeled "FLASH ICT" or "FLASH JTAG", etc.)
>
> That would, for our purposes, be preferable to my theory above.
> Simpler in some respects, but it makes each board cost more; if they
> did them in high volume, they may have spent money on their
> manufacturing equipment to allow them to make each board cheaper.

The "added cost" can be zero.  You can (depending on the volume) even
leave out the need for a *connector*... just put some convenient *pads*'
someplace and let your in-circuit *tester* do the job for you...

> >> without needing to invest a dozen times the sunray's cost in JTAG
> >> interfaces or ICE boards for the cpu in question.  Thus the
> >> signature-forging question.
> > JTAG interface is a few low speed pins on a parallel port.
>
> Oh, there's no minimum speed requirement for it?  The one JTAG box I've

Usually, the JTAG interfaces run at DC.  Essentially, suitable points on
the chip are driven by (for inputs) or fed into (for outputs) a 2-to-1 mux.
The other input for this mux comes from a 1 bit latch.  So, for inputs, the
"regular signal" (which could be a pin on the chip or even some signal
deep inside the chip -- depending on where this "access point" is
located in the design) can be routed *through* the mux to the appropriate
"input" in the circuit (i.e. "normal operation").  *Or*, the contents of
the latch can be fed in it's place.  This obviously allows you (the Tester)
to inject signals of your own chosing at each point where a JTAG node is
located.  Likewise, for outputs, the mux can pass either the "normal"
output signal through *or* the contents of that one bit latch.   (i.e. the
JTAG cell is identical for inputs and outputs.... it's just a question of
how you look at the role of the cell in yourr testing...  does it feed
something *into* the circuit or *out of* the circuit).

All of these JTAG cells are tied together in one *long* shift register.
So, using a very lean external interface (4 pins, usually -- clock, mode,
in and out), the Tester can control a large number of signals -- inputs
and outputs -- throughout the device.

The chain of JTAG cells in one device can be cascaded with those in
the *next* device, etc.  The shift register just gets longer!  Or, the
design can clock different JTAG chains in parallel -- at the expense of more
"in" and "out" pins in the JTAG interface but at the advantage of cutting
the number of (JTAG) clock cycles required to drive/sense each signal
in the chain.

> used was relatively high speed - in the low tens of MHz, I think it
> was - and I assumed the JTAG interface spec called for that.  If they
> can go as slow as dc, then sure, that'd be fine.

As you can see, three output pins and one input will do the trick.
The practical limitations of using something like a PC's parallel
port to do this are the time required to set a pin high, then set it
low, etc. -- required for each "clock" cycle you want to create.
Impractical for a production tester (hence the desire for JTAG
"programmers" that run *fast*) put perfect for hacking together
something on a bench.

Note, also, that the simplicity of the JTAG cell means that you
can clock the interface *really* fast.  There is very little logic in the
signal patch from one cell to it's successor so you're just clocking
a really *long* shift register -- length doesn't affect clock speed!

> > Biggest hassle is figuring out *if* the interface exists, etc.
>
> Well, yeah, there's that. :-)
>
> Makes me wish I had one to open up and look at.  I hate speculating in
> a vacuum.

Well, there are more painful things that can be done in a vacuum...  :>