Subject: Re: New life for Sun Ray 1s
To: None <port-sparc@netbsd.org>
From: Don Yuniskis <auryn@gci-net.com>
List: port-sparc
Date: 06/15/2002 10:47:03
> "der Mouse" <mouse@Rodents.Montreal.QC.CA> exclaimed:
> >>> [...Sun Ray 1...]
> >> I have reverse engineered SunRay flash image and I think it's not
> >> possible to boot NetBSD on it without soldering work. [...]
> > If its FLASH, then its reprogrammable in a flash, hence the name!
>
> Yes, but if it's soldered to the board, it's only as reflashable as the
> surrounding electronics makes it. That's why the remarks about
> replacing it with a socket, so you can pop the chip out and reflash it
> without depending on the sunray to do it. (Based on the "everything
> must be signed" silliness someone else sketched, this sounds as though
> it may be the only feasible approach.)
>
> Hmm. If you boot Sun's code, does it bring up a real OS, or just
> something X-terminal-ish? I'm thinking that if it's a real OS and
> supports any way of getting user code into the kernel (LKMs and such),
> its security could probably broken that way.
>
> Is its RAM socketed? In principle, you could pop that out and plug in
> dual-ported RAM, and do surgery on stuff on the fly that way.
It's hard to believe Sun flashes the devices and *then* solders them to the
board (though this is quite possible for high volume builds *if* the flashes
are all *identical* -- i.e. no serial numbers!)
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.
Schemes I have used in the past include:
- using a JTAG port on the CPU to "manually" drive the address and
data buses to the desired levels to access and then write the flash
(sort of like single-stepping the processor though this is done
automatically by an external JTAG writer)
- holding the CPU in reset and overdriving the bus from a set of
strategic test points (or even the pins of the flash device itself if it
uses a package on which the pins can be easily accessed -- DIP,
SOIC, etc.)
- shadowing execution to an off-board memory device which
replaces the flash in the IPL portion of the address space; this
off-board device containing code to program the flash (which has
been relocated elsewhere in memory). Note that this off-board
device could conceivably just use an existing "expansion card"
socket to interface to the processor -- no real added cost except
for this one-of-a-kind "expansion card"
Sorry, don't have one to give you any more concrete clues...
--don