SUN OBP / PROM Spielerei

Liegt eigentlich nicht mehr in dem Bereich den das AV.IO kann, aber zeigt trotzdem was halbwegs brauchbares: TurboGX+ mit VESA 2048x1152x60 (reduced blanking). Das ganze flimmert deutlich, ist aber zumindest lesbar. Ich kannte die Auflösung nicht bevor ich das VESA Dokument gelesen habe...

Die Auflösung ist sicher nicht so nützlich weil wohl kaum jemand einen Bildschirm dafür hat. Cool ist aber, dass die TGX+ bei dieser Auflösung sogar noch Hardware-Beschleunigung hat! Die geht nämlich nur bei bestimmten Bild-breiten, und zwar: 1024, 1152, 1280, 1600, 1920, und eben 2048.

Vielleicht kurz was dazu wie ich die verschiedenen Modi gerade teste, das ist nämlich ganz interessant was SUN sich da tolles überlegt hat

Ich teste gerade veränderten FCode (bzw. immer wieder verschiedene) auf der TGX+ ohne das verlötete EPROM von der Karte entfernt zu haben. Dazu arbeite ich mit zwei Geräten: der SPARCstation LX als Test-System und einer SPARCstation 20 als Entwicklungs-System. Auf der SS20 ist die Entwicklungsumgebung installiert, also das Paket SUNWfcode mit dem (de)tokenizer was ich oben schon erwähnt hatte. Die LX ist so eingestellt das weder für den internen Framebuffer noch für die TGX+ der FCode geladen wird. Dazu ist sbus-probe-list = 412 gesetzt, also SBUS slot 0 (die TGX+) und slot 3 (interne cg6) sind aus der Liste entfernt.

Entwicklungs- und Test-System sind seriell verbunden, Entwicklungssytem läuft und serielle Verbindung zum Test-System mit tip ist aufgebaut. Jetzt starte ich das Test-System und gehe ins OBP, also zum ok prompt. Dort kann ich jetzt über die serielle Verbindung den FCode für die TGX+ laden indem ich auf dem Test-System einfach dlbin eingebe und dann auf dem Entwicklungssytem ~C cat datei.fcode. Sobald sich der ok prompt zurück meldet kann ich das TGX+ device anlegen und den geladenen FCode ausführen. So sieht das dann aus:

SPARCstation LX, No Keyboard
ROM Rev. 2.10, 32MB memory installed, Serial #12365871.
Ethernet address 8:0:20:bc:b0:bf, Host ID: 80bcb0bf.

Type help for more information
ok dlbin
Ready for download.  Send binary file.
~CLocal command? cat sun-tgx+-vesa.fcode

away for 0 seconds
!
ok 0 0 " 0,0" " /iommu/sbus" begin-package
ok 4000 1 byte-load
cgsix
ok end-package

Und schon habe ich meinen veränderten FCode geladen und kann zB neue Auflösungen und Pixel-Clock Frequenzen testen!

Eine andere Möglichkeit ist es den FCode über TFTP zu laden wie das zB auch beim netboot mit dem Kernel gemacht wird.

Genauer beschrieben steht das ganze in Writing FCode 2.x Programs und im OpenBoot Command Reference Manual.

Inzwischen habe ich einen Test-Monitor für 1600x1200 (einen EIZO FlexScan L985EX), hier ein Foto:

Das Bild ist absolut perfekt! (Sowohl mit der TurboGX+ als auch mit dem internen Framebuffer.)

Und noch einBild vom aktuellen "Versuchsaufbau"

Mit der LX lässt sich bei 1600x1200 hervorragend arbeiten! Sie steht jetzt erstmal neben (einer) meiner VAXstation 3100:

Ich habe mir mal ein wenig die cg14, also den onboard FrameBuffer der SPARCstation 20 angesehen. Der FCode steckt wie bei der onboard cg6 der LX im PROM mit drin. Ich bin inzwischen soweit dass ich den FCode detokenized habe und soweit aufgeräumt/korrigiert dass der tokenizer wieder genau den ursprünglichen FCode reproduziert. Eine weitere gute Nachricht: der FCode für die cg14 ist identisch für die OpenBoot Versionen 2.25 von SUN und die ROSS Version 2.25r. Das spart Arbeit, denn zumindest mit den beiden Versionen sollen die Anpassungen am Ende laufen.

Hier gibts schonmal die Logos die im cg14 / SX FCode enthalten sind:

logo0.png   logo1.png   logo2.png

Die waren natürlich wieder in einem anderen Format gespeichert als bei der cg6, so dass ich also wieder extra ein Programm zum extrahieren schreiben musste... wäre ja auch zu bequem sonst!

Das Logo der cg6 hatte ich als jpg angehängt, deswegen hier noch mal verlustfrei als png:

logo.png

Zitat von ThoralfAsmussen

Da fragt man sich ja irgendwie, warum das von SUN in der Form nicht angeboten worden ist. Am dann fehlenden Doublebuffering kann es ja eigentlich nicht gelegen haben.

Von SUN gab es ja im Prinzip schon auch sehr hochauflösende Bildschirme, deswegen gibt es ja bei der LX auch die 1600x1280x76 Auflösung. Ich muss zugeben dass ich nie so einen Monitor gesehen habe, aber es gab sie. (Ich vermute einfach mal die waren extrem teuer.) Noch früher (mindestens zu sun-3 Zeiten) gab es auch schon die mono 1600x1100 Monitore.

Zitat von ThoralfAsmussen

... - was eigentlich jetzt doch mal die Frage aufwirft - wieviel VRAM hat den die LX nun - 1MB ? oder 1MB normal + 1MB Extra VRAM ? Das würde dann besser passen. Siehe oben SUN OBP / PROM Spielerei ; LX mit 1600x1200 x60 Hz und ExtraVRAM

Es ist 1MB onboard verlötet und dann gibt es einen VRAM Steckplatz für ein zusätzliches 1MB Modul, also zusammen maximal 2MB. 1152x900 geht mit 1MB, 1280x1024 dann natürlich schon nicht mehr.

Gute Nachrichten zur CG14 / SX: der Quellcode ist jetzt soweit dass sich exakt der (binäre) FCode reproduzieren lässt. D.h. jetzt kann ich anfangen Änderungen vorzunehmen, das PROM zu patchen, und die Änderungen zu testen. Zumindest theoretisch, denn dazu fehlt mir im Moment noch das VSIMM... aber das kommt hoffentlich demnächst irgendwann!

Außerdem habe ich eine schöne Überraschung im Quellcode gefunden: die Register-Werte mit der die Frequenzen programmiert werden kamen mir bekannt vor, und tatsächlich sind es genau die gleichen Zahlen (in umgekehrter Reihenfolge und um 4 bit verschoben) wie bei der CG6 der SPARCstation LX. Ich vermute mal da werkelt im Hintergrund der gleiche ICS1562 User Programmable Clock Generator. Das ist natürlich sehr schön und erleichtert das Projekt ungemein

Ich habe jetzt einen geeigneten Test-Monitor um mit der TGX+ weiter zu machen und auch schon einen ersten Erfolg: 1920x1200x60 läuft mit meinem NEC MultiSync EA244WMi einwandfrei

Ganz die VESA Auflösung ist das nicht: ich konnte 193MHz programmieren und Sync Polarität ist H/V neg/neg während VESA 193.25MHz mit Sync Pol H/V neg/pos wäre. Läuft aber zumindest mit diesem Monitor trotzdem.

Zur Erinnerung: das ist die gleiche Einstellung mit der mein AV.IO nicht oder sehr schlecht zurechtkam (post weiter oben). Evt wegen der falschen V-Sync Polarität?

Ich hatte weiter oben beschrieben wie man FCode per serieller Verbindung laden kann und so leicht testen ohne das EPROM austauschen zu müssen. Hier noch eine kurze Beschreibung wie das ganze auch per Netzwerk geht. Nicht umsonst war der SUN Slogan lange Zeit "The Network is the Computer" !

Wie oben sollte man das Gerät aus der NVRAM Variablen probe-sbus-list entfernen und mit reset neu starten. Jetzt kann man statt mit dlbin über seriell mit dload datei eine Datei über das Netzwerk laden. Dazu müssen wie beim normalen netboot der RARP und der TFTP Dienst laufen. Auf einem Solaris 2.x Server geht das zB einfach durch das einfügen einer Zeile 80:00:20:c0:ff:ee java in /etc/ethers und 192.168.0.69 java.domain java in /etc/hosts und durch anlegen des Verzeichnisses /tftpboot. Dann muss nur noch in /etc/inetd.conf der tftpd aktiviert werden (Kommentar-Zeichen entfernen) und der Server neu gestartet werden. Geht natürlich auch ohne Neustart, ist ja kein Windows, dann muss man aber wissen dass der TFTP Dienst über das NFS Skript gestartet wird

Wenn der Teil erstmal läuft, dann kann das Testsystem per netboot Dateien vom Server laden. Per Hand kann ich jetzt den FCode für ein Gerät welches nicht in der sbus-probe-list steht nachladen mit den folgenden Zeilen:

8000 dload datei.fcode
0 0 " 1,0" " /sbus" begin-package
8000 1 byte-load
end-package

(Das ist jetzt für SBUS Slot 1 auf einer sun4c Architektur. Auf sun4m muss da " /iommu/sbus" stehen.)

Jetzt will ich diesen kram natürlich im Test-Zyklus nicht jedes mal von Hand eingeben müssen!

Statt binären FCode zu laden kann die SUN auch Forth Code über das Netzwerk laden. Das kann ich dazu nutzen die Zeilen oben einfach auf dem Server in eine Datei /tftpboot/loader.fth zu schreiben und dann auf dem Testsystem boot net:,loader.fth einzugeben. Oder noch besser: ich setze die NVRAM Variable boot-device = net:,loader.fth. Wichtig ist dabei dass die Forth Datei mit einer Kommentar-Zeile anfangen muss, denn daran erkennt das OBP was es mit der Datei tun soll!

Das Ergebnis ist folgendes: wenn ich das Testsystem starte wird nach dem Banner zuerst die Datei mit den Forth Kommandos geladen und diese lädt dann den FCode. In den FCode kann ich natürlich auch gleich noch mehr mit reinschreiben, in meinem Fall hier die Zeilen um die gerade zu testende Auflösung einzustellen.

Für mein Testsystem (eine SPARCstation IPX) sieht die loader.fth Datei wie folgt aus:

\ Loads the TurboGX+ FCode via TFTP
8000 dload sun-tgx+-vesa.fcode
0 0 " 1,0" " /sbus" begin-package
8000 1 byte-load
end-package

cd /sbus/cgsix@1,0
\ r1920x1200x60 4
r1440x900x60 4
" /sbus/cgsix@1,0" " override" execute-device-method drop
install-console
banner

und der Bootvorgang sieht dann so aus:

WARNING: Unable to determine keyboard typescreen not found.

SPARCstation IPX, No Keyboard
ROM Rev. 2.9, 32 MB memory installed, Serial #3894675.
Ethernet address 8:0:20:3b:6d:93, Host ID: 573b6d93.


                                                                      
Boot device: /sbus/le@0,c00000:,sun-tgx+-vesa-loader.fth   File and args: 
Boot device: /sbus/le@0,c00000:,sun-tgx+-vesa.fcode   File and args:  
aa00 

Kurz danach erscheint dann das Bild auf dem Bildschirm, oder eben auch nicht. Das einzige was ich auf dem Testsystem noch mache ist reset eingeben, alles weitere macht es automatisch. Welche Auflösung gerade getestet wird steht in der loader Datei.

Auf diese Weise konnte ich inzwischen folgende Auflösungen erfolgreich testen mit der TGX+ an meinem NEC MultiSync EA244WMi:

1280x1024x60

1600x1200x60

1440x900x60

1920x1200x60

2048x1152x60r (das kann der Monitor eigentlich nicht, wird aber erfolgreich erkannt und angezeigt!)

Ich habe es leider noch nicht geschafft eine brauchbare Einstellung für 1920x1080 zu finden. Schade, denn das würde auch die LX noch mitmachen.

FCode testen auf der TGX+ funktioniert zwar und ist auch schön und gut, aber es gibt ein Problem: sobald ich boot eingebe wird erstmal ein reset ausgeführt und dabei geht der eben geladene FCode gleich wieder verloren. D.h. mit meinem Test-Setup komme ich nicht über das OBP hinaus. Ich vermute mal es gibt da einen Weg, aber ich weiß gerade nicht wie.

Deswegen, und auch um meine Änderungen permanent zu machen, habe ich bei einer meiner TGX+ das PROM entfernt und durch einen PLCC-32 Sockel ersetzt. So konnte ich jetzt also das EPROM schreiben und in den Sockel stecken, und schon wird es ganz normal geladen. Dann einfach nur output-device = screen:r1920x1200x60 setzen und freuen

Übrigens hat sich meine alte NetBSD (2.1) Installation auf der IPX mit der ich gerade teste direkt beim booten aufgehängt an der Stelle wo normalerweise von schwarz-auf-weiß SUN console zu wscons grün-auf-schwarz gewechselt wird. Da hat wohl jemand ein paar Annahmen gemacht die ich gerade gebrochen habe... Ich habe aber Grund zu der Annahme dass das Problem mit neueren NetBSD Versionen nicht mehr auftritt.

Solaris 2.5.1 lässt sich einwandfrei installieren. Mir gefällt die hohe Auflösung mit OpenWindows übrigens noch wesentlich besser als mit CDE.

Mir ist natürlich klar dass nicht jeder von solchen Hardware Modifikationen begeistert ist, kann ich auch verstehen. Für mich geht das Sockeln des PROMs noch in Ordnung und es ist zumindest soweit reversibel dass ich das original PROM wieder einbauen kann. Theoretisch natürlich auch wieder auflöten...

Deswegen möchte ich hier auch noch auf eine andere Möglichkeit hinweisen: es ist möglich das original PROM zu belassen und "einfach nur" größere Teile davon im nvramrc zu überschreiben. Das macht natürlich mit nvedit nicht so viel Spaß und geht außerdem verloren wenn mal wieder die NVRAM Batterie leer sein sollte. Zum Glück hat jemand ein paar Skripte geschrieben die den Prozess erleichtern sollen: https://github.com/rdolbeau/SunTurboGX . Ich habe den Code noch nicht getestet und bin nicht sicher ob der unter SunOS/Solaris läuft oder nur unter NetBSD. Das sollte aber keinen großen Unterschied machen.

Zitat von isoriano

Sollte ich jemanden finden der für den MBUS/SBUS Projekte entwickelt, der bekommt sofort meine Kohle Eine schöne WLAN Karte, 24 Bit Grafikkarte mit HDMI Ausgang etc .. ach da fallen mir so viele Sachen ein

Es gibt da nur ein mir bekanntes Projekt von Romain: https://github.com/rdolbeau/SBusFPGA

Ich hatte mit ihm ein paar mal geschrieben und er hat zumindest als Fernziel angedacht auch mal eine Grafikkarte in FPGA zu implementieren. Schon jetzt finde ich das Projekt sehr beeindruckend!

Zitat von ThoralfAsmussen

Was aber zum Beispiel sehr unschön ist, sind solche Sachen wie zersägte Gehäuse oder abgesägte Platinen.

Sehe ich auch so. Gerade mit den SUN Lunchboxen habe ich das auch schon ein paar mal gesehen dass Leute den Inhalt einfach entsorgt haben und dann ein mini-ITX board verbaut haben. Furchtbar!

Neu-Entwicklungen und Firmware-mods finde ich persönlich super, gerade auch weil man dabei viel über die Hardware lernt.

Hier noch mal ein Bild vom aktuellen Aufbau der LX mit zwei TGX+, macht also eine 5440x1200 Auflösung Die externen Festplatten und CDROM Laufwerk stehen außerhalb vom Bild.

Ein paar weitere Logos habe ich noch extrahieren können, auch die Sonne die flowerking gerne haben wollte.

SBUS

Das alte bekannte logo, einmal in schwarz-weiß und einmal in Sun Blau (das ist exakt #6441b4). Bei mir im Browser wurde die Farbe falsch dargestellt, nach dem runterladen aber richtig. (In Firefox kann man in about:config auch gfx.color_management.mode = 0 setzen um das Problem zu beheben.)

sun-logo.pngsun-logo-blue.png

Das 8-bit TCX logo der SPARCstation 4.

fsv-logo.png

Das logo der RasterFLEX HR. Hier fehlt die Farbzuordnung bzw. die Firmware setzt keine color map. Ich gehe davon aus dass die per default verwendete die übliche (3,3,2)-bit Tabelle ist. Passt für mich von den Farben her auch zum Bild, ich bin allerdings auch leicht Farbenblind

rfx-logo.png

Das logo meines SPARCbook 3 (P9000 framebuffer).

UPA

Creator 3D

ffb-logo.png

Elite 3D

afb-logo.png

PCI

XVR-100

xvr100-logo.png

Gerade bei den PCI Karten fehlen da noch so einige. Wäre natürlich cool wenn Leute hier ihre Firmware images beisteuern würden (die XVR-100 ist meine einzige SUN PCI Grafikkarte.) Ich beschreibe gleich mal wie das geht.

OK, also PCI firmware auslesen über das OpenBoot (hier 3.x) am Beispiel der XVR-100. Das ganze sollte man damit das was bringt per serieller Verbindung machen und mitprotokollieren, unter Linux zB mit dem Program script.

Zuerst mal zum entsprechenden device wechseln und properties anzeigen lassen, in meinem Fall:

ok cd /pci/SUNW,XVR-100
ok .properties
[...]
reg                      00800800 00000000 00000000 00000000 00000000
                         ^^^^^^^^ ^^^^^^^^ ^^^^^^^^
                         02800830 00000000 00000000 00000000 00020000
                         ^^^^^^^^ ^^^^^^^^ ^^^^^^^^
[...]

Für unsere Zwecke relevant ist nur das reg property. Jede Zeile beschreibt einen Speicherbereich: die ersten 3 Einträge die Adresse, die letzten 2 die Größe. Wir brauchen die Zeile bei der der erste Eintrag mit 00 anfängt ("configuration space") und die Zeile bei der der erste Eintrag mit 30 endet ("expansion rom").

Jetzt müssen wir durch schreiben in den configuration space den Zugriff auf die Firmware erlauben: (die erste Zahl hier haben wir gerade herausgefunden, der Rest bleibt immer gleich)

ok 800800 4 + dup config-w@ 2 or swap config-w!
ok 800800 30 + dup config-l@ 1 or swap config-l!

Schließlich das expansion rom (also die Firmware / den FCode) mappen und auslesen: (die ersten drei Zahlen sind hier jetzt die für das expansion rom in umgekehrter Reihenfolge, dann die Größe 20000 also 128kb, also die letzte Zahl der reg Zeile)

ok 0 0 2800830 20000 map-in
ok 20000 dump
          \/  1  2  3  4  5  6  7   8  9  a  b  c  d  e  f  v123456789abcdef
fff08000  55 aa 34 00 00 00 00 00  00 00 00 00 00 00 00 00  U*4.............
fff08010  00 00 00 00 00 00 00 00  1c 00 00 00 50 43 49 52  ............PCIR
fff08020  02 10 59 51 00 c0 18 00  00 00 00 03 5b 00 04 00  ..YQ.@......[...
fff08030  01 80 00 00 f1 08 3b 46  00 00 b5 1c 12 42 00 00  ....q.;F..5..B..
fff08040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
fff08050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
fff08060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
fff08070  c7 bf 00 00 02 10 08 09  00 00 00 00 00 00 00 00  G?..............
fff08080  52 12 0c 53 55 4e 57 2c  58 56 52 2d 31 30 30 01  R..SUNW,XVR-100.
fff08090  14 12 04 6e 61 6d 65 01  10 12 0d 53 55 4e 57 2c  ...name....SUNW,
fff080a0  33 37 35 2d 33 31 38 31  01 19 12 07 64 69 73 70  375-3181....disp
fff080b0  6c 61 79 01 1a b6 09 63  6f 70 79 72 69 67 68 74  lay..6.copyright
fff080c0  08 00 b7 12 29 43 6f 70  79 72 69 67 68 74 20 28  ..7.)Copyright (
fff080d0  63 29 20 32 30 30 33 20  53 75 6e 20 4d 69 63 72  c) 2003 Sun Micr
fff080e0  6f 73 79 73 74 65 6d 73  2c 20 49 6e 63 2e c2 b6  osystems, Inc.B6
fff080f0  06 73 63 63 73 69 64 08  01 b7 12 20 40 28 23 29  .sccsid..7. @(#)
fff08100  78 76 72 31 30 30 2e 66  74 68 20 32 2e 33 20 30  xvr100.fth 2.3 0
fff08110  33 2f 31 30 2f 31 37 20  53 4d 49 20 c2 b6 0a 70  3/10/17 SMI B6.p
fff08120  72 74 2d 73 63 63 73 69  64 08 02 b7 08 01 90 08  rt-sccsid..7....
fff08130  00 90 c2 10 00 00 00 ff  10 00 00 00 ff 10 00 00  ..B.............
fff08140  00 ff 10 00 00 00 ff 7f  b6 06 6e 75 6d 2d 33 32  ........6.num-32
fff08150  08 03 ba b6 05 78 2d 6e  75 6d 08 04 b7 08 03 23  ..:6.x-num..7..#
ESC[7mMore [<space>,<cr>,q,n,p,c] ? ESC[m^M c
fff08160  c2 b6 03 61 6e 64 08 05  b7 08 04 49 08 04 23 c2  B6.and..7..I..#B
fff08170  b6 02 6f 72 08 06 b7 08  04 49 08 04 24 c2 b6 06  6.or..7..I..$B6.
fff08180  6c 73 68 69 66 74 08 07  b7 27 08 04 c2 b6 06 72  lshift..7'..B6.r
[...]

Bei der Eingabe-Aufforderung einfach c drücken und schon wird der ganze Kram ohne weitere Unterbrechung ausgegeben. Dauert natürlich ein wenig bei 128kb...

Die ersten zwei Bytes der Ausgabe sollten 55 aa sein, sonst stimmt irgendwas nicht!

Zitat von flowerking

Ich hoffe, du hast nichts dagegen

Natürlich nicht! (Die Logos gehören mir ja auch nicht. Ich bin schon froh wenn ich nicht irgendwann von Oracle verklagt werde...)

Zitat von isoriano

Doku zum SBUS hab ich tatsächlich gefunden und auch die alten Handbücher .. "Writing Device Drivers", "Writing FCode 3.x Program", "SBus Specificaton B.0"

Viel mehr kenne ich auch nicht an allgemeiner Doku. Also es gibt noch das ältere "Writing FCode 2.x Programs" und die "Solaris 2.5.1 Driver Development Kit Introduction". Außerdem noch ein Buch von James Lyle mit dem Title SBUS - Information, Applications, and Experience (Springer-Verlag). Falls du es nicht findest auf den üblichen Seiten sag bescheid, ich kann dir das PDF schicken.