Garbage from Ultra 60 serial port - won't boot
I have an Ultra 60 that won't boot. It won't even start POST. I connected a PC to the serial port and confirmed that the terminal emulation works by connecting it to another Ultra 60 that works fine. The POST information displayed properly.
Unfortunately, the Ultra 60 that doesn't work displays nothing but garbage from the TTY port when the system is turned on. I tried various baud, parity, and stop bit settings thinking that the previous owner might have changed those settings, but I still get only garbage to the terminal.
Any ideas on where to look or how to possibly set the terminal settings back to the standard 9600 8/N/1?
# 1
Try to press Stop-N and the power on the Ultra 60 - this sets the OBP to defaults...
as at 2007-7-6 19:55:22 >
# 2
I thought I did that, but maybe my timing was off. At the risk of sounding like a Joe User, do I press and hold Stop-N then turn the system on or do I turn it on then press Stop-N before I see anything on the serial port?
# 3
It's OK to power it up then reach to the keyboard and hold the STOP and the N keys.
You will need to continue to hold them until you begin to see something on the monitor.
That's an uncomfortable stretch of the hand for some people,
but the keys need to be held through all of POST,
until the computer finally progresses high enough in the process to enter OBP.
The visual clue that the process has gone far enough
will be when the signal is finally sent to the screen.
That's when you can release the keyboard keys.
# 4
Got it. I'll try that tonight.Danke!
# 5
No dice. Stop-N didn't do anything. The screen still comes up with garbage.
There *is* a discernable pattern to the garbage, so I'm quite certain that it's displaying the same message each time. But it's still gabage and the system just stops. I even moved the PROM protection jumper from r/o to r/w. No difference.
I would consider swapping out the PROM chip with my good U60 just to see if it works, but I don't want to risk damaging the good PROM.
Any possibility that it's transmitting in something other than VT100? I'm guessing that Stop-N would normally take care of that as well, but I figure that it doesn't hurt to ask.
Any other ideas?
Message was edited by:
John_Berger
# 6
Interesting. I pressed and held Stop-D to try to force it into diagnostic mode, and it displayed much more information (aka "garbage") on the screen. So, it definitely recognized the Stop-D. I just don't know what in blazes it was displaying.
# 7
You 're seeing more garbage after STOP-D, because this sets also verbosity level to max.
You can try to use a disk with a working Solaris installation (maybe from your working Ultra60), and try to connect via telnet/ssh, if it comes up - if that works, you can use eeprom to display/change OBP variables.
as at 2007-7-6 19:55:22 >
# 8
No can do. It never gets past POST.
# 9
Hello John,
if you want to swap the NVRAM/Timekeeper between the two Ultra 60, I would recommend that you install the timekeeper from the "faulty" Ultra 60 in the working one. If you install the timekeeper from the working system in the faulty one, there is the risk that the contents is invalidated (invalid checksum).
As a precaution capture the output of the OBP commands .idprom (that's dot idprom), printenv and devalias on the working system, this data might be valuable if the IDPROM must be reprogrammed (using the NVRAM FAQ).
A faulty NVRAM can cause these errors.
Michael
# 10
I put the OBP chip in the working Ultra 60. Not only was there no problem, the OBP from the "bad" system is at the final version already. Stop-N worked fine as did "set-defaults". When I put it back in the "bad" Ultra 60, crash and burn with garbage on the output port.
I also checked the jumper settings of an identical U60. They're all the same.
What are the chances that the NVRAM chip (P/N 525-1701-08), which of course cannot be replaced, is fried or lost its programming?
# 11
Hello John,
some clarification:
NVRAM/Timekeeper socketed - contains battery backed RAM with configuration information and the real-time clock.
OBP (flash ROM) soldered to the systemboard - contains OBP/POST (aka PC BIOS).
The flash procedure overwrites the POST with the updated OBP, verifies the contents and only if the verification was successful, advances. By a failed OBP update you loose the POST, the original OBP is untouched until the new one is successfully programed.
This is an excerpt from a sample OBP/POST update (with comments).
The Flash programming process is about to begin.
Type h for help, q to quit, Return or Enter to continue:
# Program new OBP into EEPROM at the location of old POST
Erasing the top half of the Flash PROM.
Programming OBP into the top half of the Flash PROM.
Verifying OBP in the top half of the Flash PROM.
# Program new OBP into EEPROM at the location of the old OBP
Erasing the bottom half of the Flash PROM.
Programming OBP into the bottom half of Flash PROM.
Verifying OBP in the bottom half of the Flash PROM.
# Program new POST into EEPROM at the location of the old POST
Erasing the top half of the Flash PROM.
Programming POST into the top half of Flash PROM.
Verifying POST in the top half of the Flash PROM.
Programming was successful.
What are the chances that the NVRAM chip (P/N 525-1701-08), which of course cannot be replaced, is fried or lost its programming?
It's not the NVRAM !
If the ROM contents is invalid or the part has failed, get a new systemboard. If the Ultra 60 is under service contract, open a service case. An Ultra 60 (from second-hand) costs a fraction of the cost of a paid service case.
Michael
# 12
I was afraid that it was the system board in some way, but I wanted to eliminate all options first. Time to hit eBay.Thanks for the assist.
# 13
You might want to check the jumpers on the mainboard to see that they are set to RS232. If they are RS423 you might get that kind of garbage regardless of the boot PROM used. See J2604 and J2605.Message was edited by: dsiminiuk
# 14
You are correct. The dice is off the table. Everything needs to be shut down and rebooted. For the weekend. Start a raffle aka petitions.Thank you,Tiffany Ongsiaco
MLB at 2007-7-6 19:55:22 >
