2 Aug
2016
2 Aug
'16
1:48 a.m.
On Sat, Jul 30, 2016 at 11:54:03AM -0700, Pete Lancashire wrote:
Remove the part and set it in a device programmer ?
Well yes :) In theory it's simple. In practice, we'll see. I suppose I
must figure out what the device is, how to program it, find out which
adress to write to, figure out what to write.
I've never done it before either, it will be fun.
/P
On Sat, Jul 30, 2016 at 11:35 AM, Pontus Pihlgren <pontus at update.uu.se>
wrote:
> On Sat, Jul 30, 2016 at 01:58:49PM -0400, alexmcwhirter at triadic.us wrote:
> > I know nothing about this machine in particular, but i know a decent
> amount
> > about other unix machines of the era. Chances are that the copy of RTU on
> > that box is licensed to the serial / id number programmed in nvram.
> Because
> > the nvram is dead, those numbers no longer match and the OS panics from
> an
> > invalid license.
>
> I think you may very well be right. I noticed that the "show" command in
> the console displays the serial number. I went back and compared it with
> the serial number printed on the back of the machine. Well, it doesn't
> match one bit. So.. I either need to figure out to reprogram the NVRAM
> (simply set serial_number doesn't work and the manual lists the
> environment variable as "permanent") or I suppose I could figure out
> where on disk the serial number is.. but it doesn't sound easy.
>
> > The TOD clock typically part of the nvram chip and loses
> > it's value after every reset. If i had to guess, i would say replace the
> > battery / nvram chip (if it's a self contained chip like the old sun
> boxes)
> > and see if you can get enough data together to reprogram it. Whether or
> not
> > the machine in question has a facility to do that like the old sun's do
> i am
> > not sure.
>
> I've battled the NVRAM death and corresponding TOD problems in SGI, SUN
> and DEC machines before but only succeded because the "set"
> functionality of the console was enough... this time I'm not so sure.
>
> /P
>
>