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
Alles anzeigen
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
Alles anzeigen
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.
