[commodorejohn]

This thread mentions that you could be able to reset that firmware password by starting the machine without NVRAM, wait for the ok prompt, reinstall the NVRAM (carefully) and use set-defaults to finally clear the firmware password. I don't remember if I ever had to do that on one of my Sun machines, but starting w/o NVRAM is definitely possible.

Well, I tried this, but it just gets stuck starting the POST and never actually gets anywhere...

Sad to hear that. Does that help to bypass the POST:

Bypassing POST

POST may be disabled and bypassed. To bypass POST:

1. Prior to powering on the system, press and hold the Stop and D keys on the
keyboard

2. With holding down the keyboard Stop and D keys, press the Power-on to turn on
the system unit.

...from https://docs.oracle.com/cd/E19127-01/ult...561-11.pdf, page 48.

There it also reads:

Additional Keyboard Control Commands

Stop Key

If the diag-level is set to either max or min and the diag-level switch?
variable is set to true and POST is not to be executed when the system unit is powered on,
press and hold the Stop key and press the Power-on key.

Note: Press and hold the Stop key for approximately 5 seconds.

Stop and N Keys

To set the system NVRAM parameters to the original default settings, press and hold
the Stop and N keys before powering on the system. Continue to hold the Stop and
N keys until the system banner is displayed on the monitor.

I don't know if the latter is equivalent to the set-defaults command or if it just resets the diag[...] NV vars.

Other idea: You could try to install a compatible NVRAM (48T59) from another Sun machine, maybe the OBP issues a set-defaults automatically in this case. It shouldn't hurt to use the NVRAM of another machine. IIRC I once successfully reprogrammed the IDPROM of my Blade 100 in an Enterprise 250 because the OPB 4.x of the Blade 100 was missing the mkp/mkpl commands and I didn't knew how to reprogram the IDPROM using Forth's c! command at that time.

I did try bypassing the POST, but it didn't pay attention to me, or I didn't do it right (Pause/Break is equivalent to Stop on PS/2 keyboards, right?) I'm not keen on shelling out $50 for a replacement part, but I may just have to...

[johnnym]

I did try bypassing the POST, but it didn't pay attention to me, or I didn't do it right (Pause/Break is equivalent to Stop on PS/2 keyboards, right?)

I think so. Say, what's used as power-on key on a PS/2 keyboard then?

Wow that machine is reluctant to cooperate.

Does Stop + N work to reset the NVRAM settings when the NVRAM is inserted? The manual says you have to hold these keys until the banner appears.

And maybe best to continue that debugging with non-essential hardware removed or disiconnected. The machine needs a minimum of four identical memory modules in the four slots closest to the CPU slots and for the glass console a graphics card. i'd remove anything else (maybe also remove power from the drives) just to see if that makes any difference.

[commodorejohn]

Power-on is actually a discrete button on the little PS/2 converter box I have (I had the damnedest time actually realizing that until I looked up the pinout for the Sun keyboard and realized it's actually its own separate line. Nice of them to not give the Ultra II any way of booting without it!) I haven't actually tried inserting the NVRAM while it's on, since I couldn't get it past the POST - can you do that before the OpenBoot prompt comes up?

Part of me thinks I should just leave it running the POST all day, in case it's just taking an oddly long time due to having a large chunk of RAM, but I'm not sure it's even getting to the memory test - it just reports that it's starting POST and then sits there indefinitely. I need to give it another go-round with the NVRAM in just so I can compare the behavior...

[Irinikus]

Aren't you able to view the POST via serial?

[commodorejohn]

Yeah, serial-port comms are what it's defaulting to. When I had the NVRAM in, it ran through some amount of POSTing and then got to the point where it prompted for the password; now, it reports that it's starting the POST and then never prints anything more (I've left it running for over an hour.)

[johnnym]

Sorry, I'm a little lost now in figuring out what your current configuration is (NVRAM in/out, keyboard connected/disconnected, etc.) and it is important to know what was tested and what was not, to work systematically. E.g. the OpenBoot 3.x Command Reference manual ([1]) says on page 30:

Caution –
It is important to remember your security password and to set the
security password before setting the security mode. If you forget this password, you
cannot use your system; you must call your vendor ’s customer support service to
make your machine bootable again.

...which I interpret as follows: (1) Either there is always a default password configured in addition to the password set by a user that the Sun customer service knows - this would be bad for our undertaking to make your Ultra2 accessible again, because we also don't know this default password - or (2) there's a specific procedure we need to follow to reset the password. I mean if the manual I linked in an earlier post says a specific key combination held at startup resets the NVRAM vars to their defaults, why should this not work to also reset the password?

[1]: https://docs.oracle.com/cd/E19455-01/806...377-10.pdf

Yeah, serial-port comms are what it's defaulting to.

That's interesting. Assuming you needed to connect the keyboard to power on the Ultra2, I wonder why it is using the serial port as console. I thought it would switch to the glass console when a keyboard is connected, except maybe if input-device/output-device are pointing to the serial port (ttya usually).

When I had the NVRAM in, it ran through some amount of POSTing and then got to the point where it prompted for the password; now, it reports that it's starting the POST and then never prints anything more (I've left it running for over an hour.)

That is with the NVRAM out, and Keyboard in, right?

What about:

Does Stop + N work to reset the NVRAM settings when the NVRAM is inserted? The manual says you have to hold these keys until the banner appears.

...then. Sorry, with "NVRAM is inserted" I didn't meant to insert it during operation but that the machine starts up with inserted NVRAM.

[commodorejohn]

Hm, interesting. So, just to be clear, this is the observed behavior:

NVRAM in, keyboard in: boots to serial console, runs some tests, prompts for a selection between booting normally, dropping to an OpenBoot prompt, or some third option I can't remember. Requires a password before actually allowing you to boot or go to OBP.
NVRAM out, keyboard in: boots to serial console, announces that it will POST, apparently hangs from there.

I can't remember if I've tested it with the keyboard out or not, but if I did the results weren't any different. (Not sure if the computer would even perceive it as "out" or not, since the adapter box has to be connected in any case.)

It's definitely interesting that it defaults to the serial console even with the NVRAM out; I thought the default behavior was to switch to the framebuffer if the keyboard was connected? It may be that the POST happens before the switch to framebuffer console? I'll double-check the seating on the framebuffer card, and I'll definitely give the NVRAM reset a try.

[commodorejohn]

Hmm...I put the NVRAM back in and got it to do the NVRAM reset once, but I haven't been able to since, and it didn't write my changes either. Also, it's throwing some errors during POST...there may be more significant issues at play here. Gonna have to experiment with this a bit more.

[johnnym]

Hmm...I put the NVRAM back in and got it to do the NVRAM reset once, but I haven't been able to since, and it didn't write my changes either.

Did you do a reset-all after making your changes to the NVRAM vars?

I seem to remember that I sometimes changed the boot-device, then booted the OS and after shutdown and restart noticed that the boot-device var had its old value (from before my change) again - but I'm unsure if this was on a Sun, Apple or IBM machine :-/. I don't have one of my UltraSPARC II driven machines at hand now, but I maybe can do some experiments on Sunday with an Enterprise 250, which should be reasonably close to the Ultra2 although it's a PCI and not a SBUS system.

Also, it's throwing some errors during POST...there may be more significant issues at play here. Gonna have to experiment with this a bit more.

Hey, but that's progress at least. Something has been changed on your Ultra2! :-) And the password is gone, right?

[commodorejohn]

No, the password's still there, which is odd.