SGI: Hardware

Altix 350 PROM update

Yesterday I finally had some spare time to play with my Altix 350 (had to move to a new
location in August with all that stuff... Everthing went well, besides some new minor scratches
in skins (SGIs and mine, of course :roll: )

However, I tried to install the current debian distribution. Doing this I discovered that the PROM
version is too old to support newer kernels. The kernel tries to boot and after loading the initrd
I find myself at the POD mode prompt...

The situation is very much like the one described here:
http://forums.nekochan.net/viewtopic.php?f=3&t=16718710

At the moment I've PROM version 4.04, dated something/2004 (pretty old...)
Seems that this is the version which comes with ProPack 4.
So updating to the one from ProPack 5 will cure the problem (I hope so...)

To no surprise the links mentioned in the thread are dead.

Is there somebody who can help me out? ;)
:A3502L: :O2000: :O200: = :O200: - :O200: :O200: :Octane: :Octane: :320: :O2: :Indigo2IMP: :Indy:
+ | d | i | g | i | t | a | l | +apple +[...] ;)
I'm just scanning Supportfolio and found:
"Linux Patch 10550: Recommended update for snprom in SGI ProPack 5"

Maybe it's in there. But access is for full account members only... :(

edit: "Linux Patch 10385: SGI ProPack 5 Service Pack 1 Release" and
Linux Patch 10548 : PROM 5.04/1.54 Update for SGI PP3SP6,PP4SP2,PP4SP3,SLES9SP3,SLES10,RHEL4,RHEL5 seem
to be interesting too...
:A3502L: :O2000: :O200: = :O200: - :O200: :O200: :Octane: :Octane: :320: :O2: :Indigo2IMP: :Indy:
+ | d | i | g | i | t | a | l | +apple +[...] ;)
I just picked up an Altix 350 on the cheap. When I power up, it says "SGI SAL Version 3.40 rel 040719 IP41"

Is 3.40 the PROM ver?

Which Operating Systems can I expect to be able to install?
aperezbios wrote: Which Operating Systems can I expect to be able to install?


Linux.

Support is in the kernel, but it's likely that not all distributions have it in the default boot. SuSE and RedHat are the SGI supported distros, but rumor has it that CentOS will work if you have the correct console set.
"Brakes??? What Brakes???"

:Indigo: :Octane: :Indigo2: :Indigo2IMP: :Indy: :PI: :O3x0: :ChallengeL: :O2000R: (single-CM)
SAQ wrote: Support is in the kernel, but it's likely that not all distributions have it in the default boot.
SuSE and RedHat are the SGI supported distros, but rumor has it that CentOS will work if you have the correct console set.


Debian also supports it when you set the right console device.

But there is a dependence between the PROM and the kernel version you can run. For newer kernels (> 2.6.17 for what
I've found) you need a at least the PROM update from ProPack5 flashed in.

My machine has currently 4.04 and runs SLES9 which is kernel 2.6.5
Of course I would like somethink newer but don't have the PROM update available... :roll:

At least I just got the SLES media so I can install a compiler (and other things) now.
:A3502L: :O2000: :O200: = :O200: - :O200: :O200: :Octane: :Octane: :320: :O2: :Indigo2IMP: :Indy:
+ | d | i | g | i | t | a | l | +apple +[...] ;)
Some more observations (may have nothing to do with the firmware):

Upon every reboot I get very different bogomips readouts from dmesg.
One or two CPUs often have a very low value while the others have
around 2000... I know its named bogomips because its just that, so maybe
it has nothing to say. Which CPUs have a high and which have a low
readout is always different after every reboot. This time it is

Code: Select all

CPU 0: base freq=200.000MHz, ITC ratio=14/2, ITC freq=1400.000MHz+/--1ppm
Console: colour dummy device 80x25
Memory: 3879872k/3935760k available (5833k code, 66208k reserved, 2242k data, 400k init)
McKinley Errata 9 workaround not needed; disabling it
Calibrating delay loop... 2077.40 BogoMIPS
Security Scaffold v1.0.0 initialized
SELinux:  Disabled at boot.
Dentry cache hash table entries: 524288 (order: 8, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 7, 2097152 bytes)
Mount-cache hash table entries: 1024 (order: 0, 16384 bytes)
Boot processor id 0x0/0x0
task migration cache decay timeout: 10 msecs.
CPU 1: base freq=200.000MHz, ITC ratio=14/2, ITC freq=1400.000MHz+/--1ppm
Calibrating delay loop... 2094.88 BogoMIPS
CPU 2: base freq=200.000MHz, ITC ratio=14/2, ITC freq=1400.000MHz+/--1ppm
Calibrating delay loop... 2094.88 BogoMIPS
CPU 3: base freq=200.000MHz, ITC ratio=14/2, ITC freq=1400.000MHz+/--1ppm
Calibrating delay loop... 16.44 BogoMIPS
Brought up 4 CPUs
Total of 4 processors activated (6282.60 BogoMIPS).


Other phenomenon observed:

I plugged a Qlogic QLA 2202 dual 1Gbit FC HBA in the 2nd PCI bus (the one that is not shared with the IO9).
In fact this card is two QLA2200 one one card together with a PCI-PCI bridge.

On bootup I see nothing concerning this HBA...
lspci shows:

Code: Select all

0000:01:01.0 Co-processor: Silicon Graphics, Inc. IOC4 I/O controller (rev 4f)
0000:01:03.0 SCSI storage controller: QLogic Corp. ISP12160 Dual Channel Ultra3 SCSI Processor (rev 06)
0000:01:04.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5701 Gigabit Ethernet (rev 15)
0000:02:01.0 PCI bridge: Intel Corp. 21154 PCI-to-PCI Bridge
0000:11:01.0 Co-processor: Silicon Graphics, Inc. IOC4 I/O controller (rev 4f)
0000:11:03.0 SCSI storage controller: QLogic Corp. ISP12160 Dual Channel Ultra3 SCSI Processor (rev 06)
0000:11:04.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5701 Gigabit Ethernet (rev 15)


So it seems that only the PCI bridge

Code: Select all

0000:02:01.0 PCI bridge: Intel Corp. 21154 PCI-to-PCI Bridge

is visible to the OS.
To me it looks like the same situation I know from the Origin family: PCI-PCI bridges are not supported behind the
XIO-PCI-bridge (Ok, in IRIX you can enable "experimental" support in the kernel). Or is it something different here?
Most likely I'll exchange the card for two QLA2200's or two QLA2340's (depending on what I can find in my spare part
boxes)
:A3502L: :O2000: :O200: = :O200: - :O200: :O200: :Octane: :Octane: :320: :O2: :Indigo2IMP: :Indy:
+ | d | i | g | i | t | a | l | +apple +[...] ;)
You might want to try building a custom kernel if you haven't yet. There are/were quite a few SGI specific options in the kernel config that may not be enabled on a generic kernel. I don't have any Itanium boxes, but it looks like there is a SGI SN-specific PCI-bridge driver in the source tree that may or may not have made it into your production kernel.
"Brakes??? What Brakes???"

:Indigo: :Octane: :Indigo2: :Indigo2IMP: :Indy: :PI: :O3x0: :ChallengeL: :O2000R: (single-CM)
SAQ, yeah, if I can get that far, I will do so, eventually, but I'm not interested in cross-compiling for IA64, and I figure *something* has to work. I can get what appears to be a fully-loaded kernel on the machine, but then whatever user-land process is responsible for making init read and write via serial isn't doing it's thing on ttySG0 at the correct baud rate.
Thanks to files send to me by guruace I was able to flash the PROM to a more recent version.
A detailed report on this will follow as soon as I managed to write everything together (next 2
days I hope.)

Debian install is just running in this very moment, but I made backups of the SLES inst so it can
be reactivated. debian will be the "production" distro simply because it fits more for my needs and
the jobs the machine should do in future. Its used in a pure private environment so I don't have to
rely on professional support etc...

I'll write some comments on installing debian in another thread when everything is up and running...
:A3502L: :O2000: :O200: = :O200: - :O200: :O200: :Octane: :Octane: :320: :O2: :Indigo2IMP: :Indy:
+ | d | i | g | i | t | a | l | +apple +[...] ;)
Voralyan wrote: Thanks to files send to me by guruace I was able to flash the PROM to a more recent version.


I too was successful in getting my firmware updated from the broken/buggy original version to 4.07, at which point I can now successfully boot something other than SLES9. Can you please let me know how you managed to get Debian installed? I have the IA64 6.0.2 install disc, and it chokes on initial kernel boot, and kicks back to the L1 controller. Which boot-time kernel parameters are you supplying, and where did you get the kernel and initrd from?
Ok, recipe for Altix 350 PROM update (as I did it):

You need:

- PROM image to be flashed (shub1snprom.bin for newer vesions x.xx-snprom.bin for older)
- HDD with FAT filesystem on it (I used a partitioned ZIP100 for this)
- most likely a well sorted box of SCSI adapters and cables

Copy the PROM image to the FAT file system on the disk. I tried CD-Rs with a FAT fs on it, but to no success (I must admit
that I don't put too much effort in this because the method with the ZIP seemed to be easier). Be sure that the file is correctly
written to the disc.

btw: Its always a good idea to check if the SCSI path is working flawlessly, especially when a lot of fancy cables and/or adapters
are used. I bricked a CD-burner once this way...

Attach the disk to the Altix and let it boot to the EFI menu. Select the "EFI shell" menu item.
If everything is well your FAT filesystem should be accessible as fs n :/
For me it is fs4:/
Then you should be able to:

Code: Select all

EFI Shell version 1.02 [12.38]
ValidMBR: LastBlock 196575 < MIN_MBR_DEVICE_SIZE 524288
Device mapping table
fs0  : Pci(1|1)/Scsi(Pun0,Lun1)/HD(Part1,Sigg1)
fs1  : Pci(1|1)/Scsi(Pun0,Lun2)/HD(Part1,Sigg2)
fs2  : Pci(1|1)/Scsi(Pun0,Lun2)/HD(Part2,Sigg3)
fs3  : Pci(1|1)/Scsi(Pun0,Lun2)/HD(Part3,Sigg4)
fs4  : Pci(1|2)/Scsi(Pun0,Lun5)/HD(Part1,Sig00000000)
blk0 : Pci(1|1)/Scsi(Pun0,Lun1)
blk1 : Pci(1|1)/Scsi(Pun0,Lun1)/HD(Part1,Sigg1)
blk2 : Pci(1|1)/Scsi(Pun0,Lun1)/HD(Part2,Sigg5)
blk3 : Pci(1|1)/Scsi(Pun0,Lun1)/HD(Part3,Sigg6)
blk4 : Pci(1|1)/Scsi(Pun0,Lun2)
blk5 : Pci(1|1)/Scsi(Pun0,Lun2)/HD(Part1,Sigg2)
blk6 : Pci(1|1)/Scsi(Pun0,Lun2)/HD(Part2,Sigg3)
blk7 : Pci(1|1)/Scsi(Pun0,Lun2)/HD(Part3,Sigg4)
blk8 : Pci(1|1)/Scsi(Pun0,Lun2)/HD(Part4,Sigg7)
blk9 : Pci(1|1)/Scsi(Pun0,Lun2)/HD(Part5,Sigg8)
blkA : Pci(1|1)/Scsi(Pun0,Lun2)/HD(Part6,Sigg9)
blkB : Pci(1|1)/Scsi(Pun0,Lun2)/HD(Part7,Sigg10)
blkC : Pci(1|2)/Scsi(Pun0,Lun5)
blkD : Pci(1|2)/Scsi(Pun0,Lun5)/HD(Part1,Sig00000000)
Shell> fs4:
fs4:\> ls
Directory of fs4:\
08/20/08  01:37a            6,291,456  shub1snprom.bin
08/20/08  01:32a            6,291,456  4.07-snprom.bin

2 Files   12,582,912 bytes
0 Dir              0 bytes

fs4:\> flash -a shub1snprom.bin
SGI PROM Flashing Utility
Flashing all nodes
Start flashing?  Press 'y' to begin, any other key to abort: Flashing node 0
...erasing sectors
................................................................................................Done.
...copying prom
source address     : 0x000000b079b7d008
destination address: 0x8000000fffa00000
size (bytes)       : 0x0000000000600000
...programming
................................................................................................Flash of node 0 complete.
Waiting for all flash operations to complete...DONE.
Flashing node 2
...erasing sectors
................................................................................................Done.
...copying prom
source address     : 0x000000b079b7d008
destination address: 0x8000008fffa00000
size (bytes)       : 0x0000000000600000
...programming
................................................................................................Flash of node 2 complete.
Waiting for all flash operations to complete...DONE.
Done flashing.


Ok, flash was successfull. The next step is important: Go to POD mode and clear all logs...
Beware: All PROM variables and EFI settings are lost after this...

Code: Select all

fs4:\> pod
POD entered via EFI command, using Cac mode
0 000: POD SysCt (RT) Cac> initalllogs
*** This must be run only after NUMAlink discovery is complete.
*** This will clear all previous log variables such as:
*** moduleids, nodeids, etc. for all nodes.
Clear all logs environment variables, and aliases ? [n] y
Clearing nasid 0...
Clearing nasid 2...
Clearing nasid 0 EFI variables...Clearing nasid 2 EFI variables................................
Clearing nasid 0 error log........
Clearing nasid 2 error log.............
....
All PROM logs cleared!
0 000: POD SysCt (RT) Cac>


Now you can

Code: Select all

0 000: POD SysCt (RT) Cac> reset


and the system should come up fine with the new PROM.

Before the flash I had

Code: Select all

001c01#0c: SGI SAL Version 4.04 reorg041203 IP41 built 03:13:26 PM Dec  3, 2004


now I am at

Code: Select all

001c01#0c: SGI SAL Version 4.87 rel070913 IP41 built 06:02:37 AM Sep 13, 2007


This version boots all newer kernels without problems (up to 2.6.30, for what I've tested).
It should be mentioned that it therefore cannot boot that older kernels anymore (e.g. the one which is shipped with the original SLES9 release)
So you have to choose what you want... ;)
But it should be possible to downgrade if one wishes to run SLES9 once again (I've 4.07-snprom.bin for this.)
:A3502L: :O2000: :O200: = :O200: - :O200: :O200: :Octane: :Octane: :320: :O2: :Indigo2IMP: :Indy:
+ | d | i | g | i | t | a | l | +apple +[...] ;)
aperezbios wrote: I too was successful in getting my firmware updated from the broken/buggy original version to 4.07, at which point I can now successfully boot something other than SLES9. Can you please let me know how you managed to get Debian installed?


See: http://forums.nekochan.net/viewtopic.php?f=3&t=16718710&p=7342876#p7342876

You will need something even newer than 4.07 to boot the kernel...
:A3502L: :O2000: :O200: = :O200: - :O200: :O200: :Octane: :Octane: :320: :O2: :Indigo2IMP: :Indy:
+ | d | i | g | i | t | a | l | +apple +[...] ;)