OPUS PM500 - Fehlermeldung im OBP: "can't clear interrupts"

    Moin Zusammen,


    Nachdem ich den "reparierten" NVRAM M48T02 eingebaut und die IDPROM-Paramater gesetzt habe, hänge ich an der Fehlermeldung "can't clear interrupts" fest. Kennt jemand von euch diese Fehlermeldung und kann mir was dazu sagen, woher diese kommt?


    Im Internet bin ich bisher nicht fündig geworden und meine Vermutung, das der Fehler von einem nicht ordentlich terminierten SCSI-Bus stammt hat sich leider auch nicht bestätigt: der Bus ist mit einem externen 50-Pin-HD-Terminator am CPU-Board und mit der Boot-Platte am anderen ende des SCSI-Busses terminiert. Bei dem Versuch von CDROM zu booten (SuSE-Linux 7.3 für Sparc sowohl als auch Solaris 2.6) bricht ebenfalls mit der Fehlermeldung ab und der zusätzlichen Meldung, dass das CDROM nicht antworten würde. Das CDROM ist auf ID6 gesetzt und die erste Platte auf ID3. Könnte es sein, das der Interrupt-Controller auf dem Board eventuell "einen an der Waffel" hat?


    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. :love:


    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. :pinch: - 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.


    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.

    Auf meinem NVRAM stand nichts. Und neben dem EPROM war noch eine weitere Kennung (6-Stellig), die ich als teil der MAC-Adresse / HostID verwendet habe - den MAC Praefix 00:80:F1 habe ich auch verwendet, ebenso die Maschinen-ID 51. Ich habe hier aber auch noch ein defektes EXOS201-Board aus einer MX300 rumliegen, von der könnte ich auch die MAC-Adresse verwenden. Dann hätte die Maschine eine SIEMNS-MAC-Adresse :D . Konfig-Mäßig habe ich mir im OBP ein "Eigentor" geschossen: die Karte befindet sich im moment in einem Endlos-Loop, weil ich mit einigen Einstellungen herumgespielt habe. Da muss ich dem IDPROM nochmal den Batterie-Stecker ziehen... ;)


    Zitat von escimo

    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:

    Nur, dass das Eichhörnchen, das in der Seite verlinkt ist nicht mehr funktioniert... ;)


    Zitat von escimo

    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?

    Ob da ein Terminator steckt oder nicht - da ändert sich nichts.


    Zitat von escimo

    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.

    Die VGA-Karte lässt sich mit der SUN-Clone-Karte kaskadieren... Aber 2.Monitor geht auch, zumal der SUN-Monitor erst das Bild von dem Sparc-Clone zeigt.


    Den Netzwerk-Adapter von 9-Pin auf 15-Pin muss ich mir noch aus der Grabbel-Kiste zusammen bauen.

    Zitat

    Nur, dass das Eichhörnchen, das in der Seite verlinkt ist nicht mehr funktioniert... ;)

    Na dann halt den: https://web.archive.org/web/20…m/squirrel/sun-stuff.html ;)


    Das Teil sollte besser den passenden RMT 51, für SS1, bekommen, denn das prüft SunOS/Solaris später noch.

    M.E.n. hat der Code auf dem EPROM nix mit der HostId zu tun.


    Ergänzend (aus unserer Konversation)


    [1] Vormals gab es einen Status über die LED, den ich aber nicht deuten kann, ohne Doku.


    https://www.youtube.com/watch?v=1ZNvkmtQJtY

    1-pause-1-1-1-1-1-1-1 (1-pause-7)


    [2] Die Belegung für Netzwerkkabel [Cabletron P/N 9372037-1.5 Rev AA 9111] ausgemsessen

    9M <--> 15F

    1 -- 6

    2 -- 9

    3 -- 10

    4 -- 12

    5 -- 13

    6 -- 2

    7 -- 3

    8 -- 5

    9 -- 4

    x -- 1,7,8,11,14,15 NC

    Besitzt jemand (zufälligerweise) Zugriff auf folgendes Dokument? Ich bin kein Mitglied bzw gehöre keine Organisation an und in dem Fall schlägt es mit USD 33.00 zu Buche.


    Eine Frechheit für den Zugriff auf fast jede Publikation von IEEE Geld zu verlangen. Ist nicht mal mehr state-of-the-art. :versohl: