Extra-Thema!? Sehr gut!
Auf was hast du die IDPROM-Werte denn gesetzt?
Die MAC-Addresse sollte hier anders lauten, d.h. die ersten drei Byte lauten anders als bei SUN mit 8:0:20. Interessant, dass da auch bei der HostID 20ffffff von deinem Foto das erste Byte auf "20" festgesetzt scheint. Das kennzeichnet i.d.R. den real-machine-type bzw Byte-1 für die konkrete Speicheradresse beim Reprogramming. Bei einer SS1 muss/sollte das der Wert "51" Hex sein! Könnt' also was eigenes von OPUS sein, denn die "20" scheint nicht reserviert zu sein, wenn man nach dem IDPROM/NVRAM FAQ geht. Eine OPUS SPARCard 2 mit OBP Version 2.4 (00EE2CF4) hat bspw auf dem NVRAM stehen:
101675
Hostid 55018d2b
Ether 00:80:f1:01:8d:2b
Wenn man das mal nachverfolgt landet man für den MAC Identifier 00:80:f1 immerhin bei ...
Also wäre die Idee beim Reprogramming Byte 1-7 mit u.a.
ok 51 1 mkp
ok 0 2 mkp
ok 80 3 mkp
ok f1 4 mkp
ok c0 5 mkp
ok ff 6 mkp
ok ee 7 mkp
[...]
ok 0 f 0 do i idprom@ xor loop f mkp
zu belegen. Oktett 4 bis 6 hier "co:ff:ee" kann dann auch was anderes valides sein.
Hat irgendwer mal angefragt. Scheint niemand konkret beantwortet zu haben, leider. Einzig mit Verweis auf das bekannte FAQ.
[SunRescue] IDPROM problem with OPUStation PM 5000
Auch mal Diag + Autoboot abgeschaltet:
ok printenv
ok setenv diag-switch? false
ok setenv auto-boot? false
ok setenv selftest-#megs 1
^ Gibt es selftest-#megs überhaupt schon in OPB 1.x ? Oh-Man! Zu lange keine mehr angeschaltet. Ich bin nur noch beschäftigt mich am Abend abzuschalten, nachdem mich unser Nachwuchs über Tag hochgespielt hat.
ok cd /
ok words
Dann könnt' man die Wörter der OPUS FW zur SS1 mit OBP 1.3 vergleichen.
Ein simples strings auf das Binary ergibt Anhang opus-pm-500-obp14-strings.txt.
Bzgl "can't clear interrupts"
Ich glaube "fast" nicht, dass der externe 50pol HD-SCSI Anschluß am Blech oder intern separat terminiert werden muss. Vorausgesetzt die HD hat SCSI ID 3, da erste Platte. Die SS1 kommt bereits mit einer automatischen Terminierung. Mal probiert einfach ohne SCSI einige Tests zu fahren, auch nur nötiges RAM eine Bank zu stecken und ggf. mal ein blinden Boot über Netzwerk zu machen, um zu schauen, dass die Meldung dann nicht mehr erscheint?
Das "fast", weil ne SIO-A Umleitung auch schon nicht zu funktionieren scheint. - Denn, wenn die SIO-A Umleitung funktionieren würde, könnte man ggf. mal die "burn-in" Manufacturing Diagnostics (POST run in a continuous loop) laufen lassen. Wenn der nicht besteht, gibt es eine Scope-Loop über.
ok setenv mfg-switch? true
ok reset
Abbruch mit L1-A (FB) oder Break (Terminal)
Aber vllt ist das hier anders realisiert, weil das Bard-Set ja i.d.R. in einem PC zum Einsatz kommt. Der Nutzer hat i.d.R. nicht noch ein Terminal nebenan stehen, eher noch einen zweiten Monitor.
Zitat
Power-On Self Test
Next, the firmware initializes the system, including the memory management
unit (MMU), keyboard, mouse, serial ports, frame buffer, and memory.
Additional initialization tasks are performed. These include, but are not
limited to, setting up interrupt vectors and trap vectors and probing for SBus
boards.
Alles anzeigen
Quelle: SS1+ FSM
Die S4 MMU beinhaltet die Interrupt Register.
Quelle: http://www.bitsavers.org/pdf/s…ogrammers_Model_Jun89.pdf
Ein Kotakt zu einem Eigentümer einer OPUS SPARCard 5 (SS5 Clone) hatte auch keine Doku und wurde dann begonnen die Leiterbahnen zu verfolgen. Allerdings funktioniete m.W.n. die Umleitung auf SIO-A. What a mess!
Solche Boards gab es bekanntlich auch mit Fairchild Clipper: http://www.decodesystems.com/help-wanted/opus.html
Aber das hilft hier nur bedingt, auch wenn schön anzusehen.