"Valeriy E. Ushakov" <uwe@ptc.spbu.ru> wrote:
> On Sun, Jun 16, 2002 at 05:52:03 +0400, Valeriy E. Ushakov wrote:
> 
> > IIRC, microSPARC-IIep can boot from either - it's selectable.
> > Unfortunately I don't have the manual on my laptop so I'll check
> 
> Grrr, finding stuff on www.sun.com is a challenge...

Agreed.  Though some chip vendor web sites make Sun's look like
an "open book"!  :-(
 
> microSPARC-IIep User's Manual
> (#802-7100-01)
> 
> 11.7 Boot Options (p. 213)
> 
> The microSPARC-IIep provides 4 boot options (see Table 11-3). The
> options are set via the BM_SEL[1:0] pins and these pins are programmer
> visible via bits 22:21 of the TLB replacement control register.
> 
> Table 11-3  Boot Mode Select (BM_SEL)
> BM_SEL[1:0] Boot From:
> 00 32-Bit Flash memory on Memory Data Bus (cacheable)
> 01 8-Bit Flash memory on Memory Data Bus (cacheable)

Presumably, only one of these two makes sense -- either a
32 bit wide device is present *or* an 8 bit device (the latter
often being a cheaper/more available manufacturing option).
Though it might be possible "by coincidence" to get the
processor to *miss* the Flash by telling it that the wrong
width device is installed and *hopng* that the instruction stream
ends up forcing a fetch from someplace accessible in memory...

For example, if a 32 bit device is installed, set jumper for
*8* bits and hope that the stream of instructions created by
"every fourth byte" (actually, by "those bytes tied to this
particular set of data bus lines") ends up causing a fetch
to someplace *predictable*.  Someplace in which you
can install some other image...

Likewise, you could "disable" the Flash's output buffers
and "pull" the data bus to the opcode for a "NoOp"
and just wait until it runs off the end of the flash into
more "hospitable" portion of memory...

> 10 PCI Bus, Addresses 0xf000.000 - 0xf0ff.ffff (non-cacheable)
> 11 PCI Bus, Addresses 0xffff.000 - 0xffff.ffff (non-cahceable)

Now *this* seems like the manufacturing back door.
Hopefully,  said bus comes to a connector for an "expansion card"?

> * For option 10, the PCIC converts the boot address (0000.0000 -
> 00ff.ffff) to the PCI address (f000.0000 - f0ff.ffff) directly in
> hardware and does not use any of the AFX to PCI translation registers.

Ah!  This lends further credibility tothat! I suspect any Flash on the
"Memory Data Bus" is ignored when this option is selected and the
"PCI" flash takes it's place.  For example, if the Memory Data Bus
Flash (clumsy term but for consistency with the option 00/01 nomenclature)
appears at memory address 0x00000000 and the PCI Flash appears
at 0xF0000000, then all this "option" does is force the 4 MSb's of the
address bus to "0xF" on RESET.  The normal system address decoder
then routes the normal "0x00000000" access for IPL to the PCI
Flash -- ignoring the Memory Data Bus Flash completely.

N.B. This forcing of the address bus could conceivably be done by 
effectively placing XOR's in those address lines.  This has the added
advantage that it allows the "real" address bus to be driven to 0x00000000
by accessing address 0xF0000000 (!).  This lets the Memory Daa Bus
Flash be accessed while in this "mode" -- so that *it* could possibly be
rewritten by the PCI Flash's code...

> * For option 11, the PCIC converts the boot address (0000.0000 -
> 0000.ffff) to the PCI address (7fff.0000 - 7fff.ffff) in hardware.
> 
> PS:  NB, option 10 is why Krups needs relocated kernel.  f000.0000 is
> occupied by OFW.

Presumably, writing the Flash is straightforward -- not protected by any
cryptic hardware (possibly an "unlock Flash" bit someplace?).  So, you
could conceivably put a ROM/Flash on a PCI card, hardwire it
to physical address 0xF0000000 and have a tiny "Flash Loader"
in taht "ROM" that just copies the rest of the image in that ROM
into the Memory Data Bus Flash (write byte; spin-wait on Flash to 
see if ready; repeat)