[jwhat]

Hi Weblacky,

on progress front, I did some digging into POD/CAC and tried testing a couple of commands, in particular:
>> A 000 001c01: Rd sysctlr nvram: scr ADDR [COUNT]

To see if I could read the PROM and validate data against the dump data.

Initially it seemed to take the ADDR and just echo'ed it as HEX so I tried to use HEX address and set what that provided:
>> scr 0x160 8 (where 0x160 was starting address of PROM where the CPU speed was stored)

This did not seem to be to provide any valid output in my initial testing so need to try again.

If you found the right PROM location then you could try:

>> A 000 001c01: Wr sysctlr nvram: scw ADDR [VAL [COUNT]]

This could be very very dangerous though as if you clobber the wrong thing it could brick the entire Fuel...

Before doing this I would like to know we had some recovery mechanism , like ability to re-program PROM chip ...

I know that you have speculated on being able to change in RAM data, but how would we know where this data is loaded (read the source code) ?
Also if the PROM was pulled into memory with slower than "PROM-ified" ;-) CPU then this would also put weight to CPU speed change on boot..

As part of your testing it might be helpful , just to see what happens if you put slower CPU into machine and see if you an get to POD/CAC mode.

If so then this would mean that machine is starting with some default CPU speed and then changes speed as part of boot process...

I think we need to make sure we have some emergency parachutes available or we get some more definitive direction.

Currently the only person who has made reference to this is Toby Jenkins/Jennings from what was 3-D Systems in UK via Nekochan...

And if he knew then it is likely he go info from a SGI field engineer, as this would allow them to upgrade customer systems without need to have root access.

Cheers from Oz,

John Hartley.