Upgraded OBP on Ultra 1 - now can't boot
Started out wqith an Ultra 1 at OBP 3.5. Upgraded it to Solaris 9. During the install I was offered (but declined) the option to upgrade the firmware to 3.11.
System booted just fine - very happy.
Then in an attack of conscience, I decided to revisit the OBP issue. Downloaded patch 104881-08 from sunsolve, followed the instructions and upgraded OBP to 3.33 (current). Install went fine. Ultra-1/Solaris 9 was listed as a supported platform in the documentation.
Now, however, every time I start the machine, I see this:
Sun Ultra 1 SBus (UltraSPARC? 167MHz), No Keyboard
OpenBoot 3.33, 128 MB memory installed, Serial #9415477.
Ethernet address 8:0:20:8f:ab:35, Host ID: 808fab35.
(Notice the ? after UltraSPARC).
When I attempt to boot I see this:
ok boot
Boot device: disk File and args:
krtld: load_exec: fail to expand cpu/$CPU
krtld: error during initial load/link phase
panic - boot: exitto64 returned from client program
Program terminated
ok
The two seem to suggest to me that OBP 3.33 cannnot properly identify the CPU.
Now I have a non-bootable machine with no apparently easy way to revert to an earlier OBP. I have the Solaris 9 12/03 media kit but have not figured out how/if I can somehow get to the embedded 3.11 PROM I was offered earlier.
Has anybody seen this?
Is it a known issue with OBP 3.33? (I notice it purportedly fixed Bugid 1205113: "dev /SUNW,<a href="mailto:UltraSPARC@0" target="_blank">UltraSPARC@0</a>,0" fails. which looks suspiciously like my problem.)
Thanks in advance,
[1663 byte] By [
anewby] at [2007-11-25 23:05:41]

# 1
I have not seen this issue before.However are you aware there are 2 types of U1. u1 and u1e.u1 requires patch 104881u1e requires obp patch 104288The u1e has a 68pin scsi connection on the back and not a 50 pin (u1)What U1 do you have?AK
AK at 2007-7-5 17:57:02 >

# 2
I have a 50-pin connnector on the back. inside, the M/B is marked 501-3082, both of which lead me to believe that it's an Ultra-1.
# 3
P.S. The patch I applied was 104881-08
# 4
anewby,
I was wondering if you have been able to boot cdrom.
if no, have you tried to use another solaris cd.
If you dont have an onboard cdrom is it possible to connect one.
Also with diag-switch? true does post pass ok?
Chat to you soon.
If I dont hear back from you today b4 end of day, ill check on tues.
rgds
AK
AK at 2007-7-5 17:57:02 >

# 5
Adrian,
Here are the current revs for various Sun platforms:
<a href="http://sunsolve.sun.com/handbook_pub/Devices/Boot_PROM/BootP" target="_blank"> http://sunsolve.sun.com/handbook_pub/Devices/Boot_PROM/BootP</a> ROM_Flash_Sun4u.html#0902
<a href="http://sunsolve.sun.com/handbook_pub/Devices/Boot_PROM/BootP" target="_blank"> http://sunsolve.sun.com/handbook_pub/Devices/Boot_PROM/BootP</a> ROM_Sun4u.html#U1_140
# 6
Now that's very interesting:
Your link points to docs that clearly state the latest OBP for Ultra1/170 is OBP 3.25 Version 0 + POST 3.10.6 . Ha ha! I think, somehow I managed to put on a rev that's too late - I'll go and get 3.25 and I'm done.
So, I followed the link to find the corrrect OBP ( <a href="http://sunsolve.sun.com/handbook_pub/Devices/Boot_PROM/BootPROM_Sun4u.htm l#U1_170" target="_blank"> http://sunsolve.sun.com/handbook_pub/Devices/Boot_PROM/BootP ROM_Sun4u.html#U1_170</a> ). More good news! - the link leads me to patch 104881-07
OBP 3.25 Version 0 + POST 3.10.6 (Flash Update 2.2), which is exactly what I want. (I appplied patch 104881-08, if you remember).
However, when I follow the hyperlinked patch number, it takes me right back to where I was before i.e. patch 104881-08 and OBP 3.33.
If I search SunSolve for patch 104881-07, I still get dropped on 104881-08. How do I get the prior rev? Does anybody out there have a copy?
# 7
The answer is - go here ...
<a href="http://lios.apana.org.au/~cdewick/data/bootroms.html" target="_blank">http://lios.apana.org.au/~cdewick/data/bootroms.html</a&g t;
It's an archive of useful Sun Patches etc.
P.S. AK - Thanks for the helpful replies - Much appreciated.
# 8
Downloadad 104881-07. Applied 3.25 OBP. System booting perfectly. Problem solved.
# 9
anewby,
Thats great news.
Considering you found a link for old obp patches.
Would you also have up ure sleeve a link where I can get old patches.
I looked on Sun Shack but with no avail
If you have that would be great.
Thanks in advance
rgds
AK
AK at 2007-7-5 17:57:02 >

# 10
Best I could come up with is this:
<a href="http://sunsite.rediris.es/sites/ftp.cert.dfn.de/pub/vendor/sun/patches/" target="_blank"> http://sunsite.rediris.es/sites/ftp.cert.dfn.de/pub/vendor/s un/patches/</a>
It claims to be a mirror of <a href="ftp://sunsolve1.sun.com/pub/patches" target="_blank">ftp://sunsolve1.sun.com/pub/patches</a> although I found the older version of the OBP patch I had been serching for. Maybe you might get lucky.
If you have an exact patch number, you might also just Google for it.
# 11
I experienced the same problem after upgrading my Ultra1-170E to OBP 3.33 using patch 104288-08
Trying to boot:
Boot device: disk File and args:
krtld: load_exec:fail to expand cpu/$CPU
krtld: error during initial load/link phase
panic: - boot: exitto returned from client program
Program terminated
Now I have downloaded the preceeding version, patch 104288-07, but I am not sure how to apply it with a machine that won't boot..
What can I do?
# 12
Remember, OBP is OS-independent so the fact you can't boot an OS doesn't mean you can't fix your OBP.
To do this, you have a couple of options I can think of:
Option 1. (Easy) If you have a CD-ROM installed on your box, you can unzip and burn the patch onto a CD. Then, from the OBP ok prompt, type:
boot cdrom /104881-07/flash-update-Ultra1-latest
Option 2. (Harder) If your shop has an installation or boot server on the network (e.g. a JumpStart installation), you can unzip the patch into that environment, making sure that it's located beneath the directory the Ultra1 would normally boot from. If you've never worked with any of Sun's over-the-net boot/installation tools before, either get some help or get ready for a lengthy (but doable) chunk of work.
Before attempting this, you will need to make sure of the following:
a. /etc/ethers has an entry for the MAC address of the machine you're trying to rescue
e.g. xx:xx:xx:xx:xx:xx some-host-name
b. some-host-name can be resolved in DNS
c. /etc/bootparams has an entry for some-machine-name
e.g. some-machine-name root=<your install server name>:/install-server/Solaris_9/Tools/Boot install=<your install server name>:/install-server boottype=:inrootopts=:rsize=32768
Note: the above assumes you're not using DHCP to supply the above information. If your shop uses DHCP, then you need to go and consult with the guy who set it up because I've no experience with that part of it.
Once your install server is set up, you can add the OBP patch to the installation.
In the example below, I'm using PATCH_TAR to indicate the tarfile you downloaded that contains the OBP patch and assuming your working with Solaris 9.
cd <install server main directory>
cd Solaris_9/Tools/Boot/platform/sun4u
mkdir flash
cd flash
tar -xvf PATCH_TAR
Now, you have a flash update image you can boot from the network like so:
boot net flash/104881-07/flash-update-Ultra1-latest
Option 2. is trickier but I know it works because that's what I ended up doing.
# 13
BTW, in the instructions above, the directory /install-server is where my JumpStart stuff lives. You'll have to change this to reflect the location of your own JumpStart installation, since they will almost certainly be different.
# 14
Thanks for your hints.
I solved my problems by a third option. I unplugged my boot disk, put it into another working Ultra1E and saved the -07 version of the patch in the root. After I've put it back I could boot the OBP3.25-version of the flash-update and make a successful update.
Best regards
-orjste
# 15
Hello,
someone on the Sun Developer Connection went into the same 'trap'.
This is a link to his thread
<b>Ultra 1E & OBP 3.33: solaris cd not booting.</b>
'<a href="http://forum.sun.com/thread.jsp?forum=6&thread=18793&tsta rt=0&trange=15" target="_blank"> http://forum.sun.com/thread.jsp?forum=6&thread=18793& ;tstart=0&trange=15</a>'
One interesting fact from the thread is that only Solaris does not work properly with the new OBP 3.33. The author (khamsun) tried with success OpenBSD 3.4, NetBSD 1.6.1 and Linux (no distribution specified).
Michael
maal at 2007-7-21 14:29:07 >

# 16
hello,
thanks for the help by crossposting to the developers forums.
I knew about the lios.apana archives of PROM images and other tech goodies.I was just afraid to downgrade the OBP , but from this thread I can see it's safe.I mean only maybe a previous existing OS can suffer from that, not the PROM itself.
So I downloaded the OBP 3.25 and burned it into a cdrom.But if I ran the last flash (from 3.7 to 3.33) by copying the update image to the / on the existing solaris filesystem and: 'ok boot disk /flash-upgrad' , this one instead was fired with a : 'ok boot cdrom:a/flash-upgrade' without success.
Trying to change the filesystem on the cdrom from regular iso9660 to a solaris bootable cdrom, by mean of the NetBSD utility 'mksunbootcd' which puts the files on a 'f' ufs slice doesn't work either.
Error message is in any case 'can't load boot file'
So I transfered and chmoded 755 the flash-update to the root slice of an OpenBSD, ie. a ffs/ufs filesystem. But that doesn't work .
In the linux kernel there is a module called 'flash.o' but it's not documented in the source tree, and I'm still looking for the utility able to to do the task from a running linux.
I can swap the disk from another box running solaris or I can netboot, but I still believe the flash can be run from cdrom...
# 17
Hello,
the original author <b>anewby</b> didn't realize that I had already posted the link to his thread.
As I probably mentioned before, the other chioce is to use the <b>SUN4U SYSTEM FLASH PROM UPDATE</b> cd. I have a stack of those cd's (not the latest ones, only version 2.3).
I personally would recommend to use a minimal installation of Solaris (no GUI) on a spare disk. Another choice is to temporarily install on the swap (!) slice (don't forget to write the bootloader to that slice) and use this one for the flash program.
But don't ask me how to reactivate the swap slice after the flash is finished...
Michael
maal at 2007-7-21 14:29:07 >

# 18
UPDATE:
Sun has just made a newer version of the flash-update patch available for both Ultra-1 and Ultra-1E systems.
patch 104288 for `E`
patch 104881 for non-`E`
version 3.35.0 fixes the problem discussed in this thread.
Also, if you should have a Spectrum login to Sunsolve,
there are a few more details in the Components section of the SSH:
<a href="http://sunsolve.sun.com/handbook_private/Devices/Boot_PROM/BootPROM_TOC.h tml" target="_blank"> http://sunsolve.sun.com/handbook_private/Devices/Boot_PROM/B ootPROM_TOC.html</a>
else you can just review the README that is included in the downloaded patch zipfile.
Bill at 2007-7-21 14:29:07 >

# 19
Hello to the group!
I have an Ultra 1 (A11) 170MHz that refuses to accept 104881-09.
I have verfied that the motherboard is truly a 501-3082 to the best of my abilities: I pulled the board, and on the corner nearest the memory slots, is a label that starts off 501-3082.
The current OBP revision is 3.25, and I successfully upgraded to that from 3.11 just yesterday. And everything works fine.
The need to run 3.35? Purely academic I suppose, as even with 3.11 the system was doing what I wanted it for :)
It just boggles me that I get this message when I attempt to load the standalone flash from 104881-09:
I have copied the standalones for both the 140 and the 170 into the root directory of a Sun bootable installation. This gives:
ok boot disk /flash-update-Ultra1-Model170-latest
Boot device: /sbus/<a href="mailto:espdma@e" target="_blank">espdma@e</a>,8400000/<a href="mailto:esp@e" target="_blank">esp@e</a>,8800000/<a href="mailto:sd@0" target="_blank">sd@0</a>,0 File and args: /flash-update-Ultra1-Model170-latest
Loading ufs-file-system package 1.4 04 Aug 1995 13:02:54.
FCode UFS Reader 1.6 04 Aug 1995 13:01:58.
Loading: /platform/sun4u/ufsboot
-
Standalone Flash PROM Update Utility, Rev. 2.8
Ultra(tm) 1
... snip...
**ERROR - There were no binary modules found. You may have loaded
the wrong Flash update file for this system, which has the
root node "model" property: SUNW,501-2836
Program terminated
This seems to indicate that I don't have a 170 board, but rather a 140. Hmm, I think.
Then I try the 140 patch
Rebooting with command: boot disk /flash-update-Ultra1-Model140-latest
Boot device: /sbus/<a href="mailto:espdma@e" target="_blank">espdma@e</a>,8400000/<a href="mailto:esp@e" target="_blank">esp@e</a>,8800000/<a href="mailto:sd@0" target="_blank">sd@0</a>,0 File and args: /flash-update-Ultra1-Model140-latest
Loading ufs-file-system package 1.4 04 Aug 1995 13:02:54.
FCode UFS Reader 1.6 04 Aug 1995 13:01:58.
Loading: /platform/sun4u/ufsboot
-
Standalone Flash PROM Update Utility, Rev. 2.8
Ultra(tm) 1
... snip..
This utility allows you to interactively update the firmware
revisions in specific system Flash PROM components.
Type h for help, q to quit, Return or Enter to continue:
This is bliss, but what will happen if I continue the update? I am assuming something bad, because this is not the correct OBP firmware update.
Just for reference:
ok reset-all
Resetting ...
Software Power ON
@(#) Sun Ultra 1 SBus 3.25 Version 0 created 1999/12/03 11:36
Clearing E$ Tags Done
Clearing I/D TLBs Done
Probing Memory Done
MEM BASE = 0000.0000.0000.0000
MEM SIZE = 0000.0000.0800.0000
MMUs ON
Copy Done
PC = 0000.01ff.f000.1c7c
PC = 0000.0000.0000.1cc0
Decompressing into Memory Done
Size = 0000.0000.0006.cc70
ttya initialized
SC Control: EWP:0 IAP:0 FATAL:0 WAKEUP:0 BXIR:0 BPOR:0 SXIR:0 SPOR:1 POR:0
Probing Memory Bank #0 64 + 64 : 128 Megabytes
Probing Memory Bank #10 +0 :0 Megabytes
Probing Memory Bank #20 +0 :0 Megabytes
Probing Memory Bank #30 +0 :0 Megabytes
Probing /<a href="mailto:sbus@1f" target="_blank">sbus@1f</a>,0 at 0,0 cgsix
Probing /<a href="mailto:sbus@1f" target="_blank">sbus@1f</a>,0 at 1,0 tr
Probing /<a href="mailto:sbus@1f" target="_blank">sbus@1f</a>,0 at 2,0 Nothing there
SC Control: EWP:0 IAP:0 FATAL:0 WAKEUP:0 BXIR:0 BPOR:0 SXIR:0 SPOR:1 POR:0
Probing Memory Bank #0 64 + 64 : 128 Megabytes
Probing Memory Bank #10 +0 :0 Megabytes
Probing Memory Bank #20 +0 :0 Megabytes
Probing Memory Bank #30 +0 :0 Megabytes
Probing /<a href="mailto:sbus@1f" target="_blank">sbus@1f</a>,0 at 0,0 cgsix
Probing /<a href="mailto:sbus@1f" target="_blank">sbus@1f</a>,0 at 1,0 tr
Probing /<a href="mailto:sbus@1f" target="_blank">sbus@1f</a>,0 at 2,0 Nothing there
Sun Ultra 1 SBus (UltraSPARC 167MHz), No Keyboard
OpenBoot 3.25, 128 MB memory installed, Serial #8448570.
Ethernet address 8:0:20:80:ea:3a, Host ID: 8080ea3a.
ok
ok .ver
MAXWIN:7 MAXTL:5 MASK:22 IMPL:10 MANUF:17
ok .version
Release 3.25 Version 0 created 1999/12/03 11:36
OBP 3.25.0 1999/12/03 11:36
POST 3.10.6 1996/10/18 10:19
ok .speed
CPU Speed : 167.00MHz
UPA Speed : 083.50MHz
SBus Speed : 025.00MHz
Am I missing something terribly obvious?
Thanks for your consideration.
# 20
Try booting in 32 bit mode, see if that helpsat the ok prompt:boot -afor the kernel type: kernel/unix
# 21
<table border="0" align="center" width="90%" cellpadding="3" cellspacing="1"><tr><td class="SmallText"><b>gandalf wrote on Mon, 02 January 2006 13:24</b></td></tr><tr><td class="quote">
Try booting in 32 bit mode, see if that helps
at the ok prompt:
boot -a
for the kernel type: kernel/unix
</td></tr></table>
Hey I appreciate your thought -- thanks for reading my post. I am wondering now, if I should have just started a new thread. I just figured it was sort of related to Sun's wacky 3.31 OBP release (I think I recall that right), that this sort of belonged here. Hindsight...
To the matter at hand.
Regardless of the kernel booted, I arrive at the same end. Of course, I only booted long enough to copy the standalone flash update into the root directory of the disk, then halted the OS.
The really striking thing here, is that the flash file for a 140 is the one that "works", and the file branded for a 170 fails with the error that basically says 'you are using the wrong firmware for your hardware, your hardware is a 140Mhz system', which is not correct, as I have physically verified the part number on the motherboard. It doesn't appear to have been forged.
<table border="0" align="center" width="90%" cellpadding="3" cellspacing="1"><tr><td class="SmallText"><b>Quote:</b></td></tr><tr>& lt;td class="quote">
You may have loaded
the wrong Flash update file for this system, which has the
root node "model" property: SUNW,501-2836
</td></tr></table>
Perhaps I can help myself by asking the question: wher eis the `root node model property' stored? Is there a chance that a person modified this value in nvramrc with the forth editor? Can I display it with a OBP/forth command?
Thanks again to all reading this thread.
Best,
Joe
# 22
Well all is well in flash-land, but I can't say I understand why. I wound up pouring over OBP documentation from various vendors, in order to understand where this root "model" property was stored.
One can use the .properties command at the OBP from the root node and voila.
ok dev / (or cd /)
ok .properties
energystar-v2
idprom01 80 08 00 20 80 ea 3a 00 00 00 00 80 ea 3a a9
reset-reason S-POR
breakpoint-trap 0000007f
#size-cells 00000002
modelSUNW,501-2836
name SUNW,Ultra-1
clock-frequency 04f9ff6e
banner-name Sun Ultra 1 SBus (UltraSPARC 167MHz)
device_type upa
Now this was on the Ultra 1/170 in question. I have many of these so I pulled another one out of the pile and lo-and-behold:
ok cd /
ok .properties
energystar-v2
idprom01 80 08 00 20 8f e7 7c 00 00 00 00 8f e7 7c a9
reset-reason B-POR
breakpoint-trap 0000007f
#size-cells 00000002
modelSUNW,501-3082
name SUNW,Ultra-1
clock-frequency 04fa05fe
banner-name Sun Ultra 1 SBus (UltraSPARC 167MHz)
device_type upa
Note the two different model strings. Again, I checked the motherboard on the first 170 and it cleary identifies as a 501-3082, yet, the .properties reveals the conflicting version. Strange. Very strange. I guess someone on the eprom assembly line was asleep the day the one was burned? heh.
So to conclude, I finally just threw caution to the wind, and burned the flash-update-Ultra1-Model140-latest into the first machine, and it seems fine.
ok .speed
CPU Speed : 167.00MHz
UPA Speed : 083.50MHz
SBus Speed : 025.00MHz
so it didn't turn into a brick, or a 140Mhz machine :)
