Gibt es ein Programm was das CMOS-RAM verändert aber nur ein BIOS Warmstart durchführt ?

1. offizieller Beitrag

    Habe folgende Überlegung als "Workaround" für leere Mainboard-Batterien:

    Das Programm muss vorgegebene Werte (bspw. Anzahl Floppy Drives, Anzahl Festplatten, Floppy-Drive-Typ, Festplatten-Typ) verändern können, und darf dann aber *keinen* Kaltstart durchführen. Damit könnte man falsche BIOS-Werte-Einstellungen sozusagen nach dem Booten noch korrigieren, und dann nur ein Floppy-/Festplatten-Reboot durchführen.

    Danach hätte bspw. DOS alle Werte so, wie man sie bräuchte, trotz leerer Batterie/kaputten Dallas RTC. Ein Austausch der Batterie wäre natürlich die nachhaltigere Lösung, aber letztendlich ist das BIOS ja auch nur ein Stück Software und sollte somit auch austricksbar sein.

    Gibt es so ein Programm ?

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey

    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.

    Seit System 7.5 (1995) gibt es so was auf dem Mac: "PRAM Auto-Restore 1.0". Der Rechner startet mit der Festplatte, die gemäß Firmware zuerst dran ist, Während des Starts läuft dieses CDEV/INIT von diesem Startlaufwerk und bastelt die Werte im NVRAM zurecht. Sinnvoll ist hier gleich eine Zeitsynchronisation durchführen zu können, falls das richtige Netz-Interface verfügbar ist. Danach startet man nochmal und alle Parameter sind so, wie man das vorher mal gesichert hatte (von der Mausgeschwindigkeit über ein anderes Startlaufwerk bis zum Anschluß für die einzelnen Netzprotokolle). Der kritische Moment ist der Start vom von der Firmware bevorzugten Laufwerk. Wenn das ein kaputtes System hat, muß man mit Tasten "zaubern", um ein anderes bekanntes Laufwerk zum Starten auszuwählen.

    Soviel als Anhaltspunkt, was zu beachten ist.

    Du kannst zwar mit dem driveparm Befehl mit passenden Parameter in der Config.sys BIOS-Einstellungen zu Floppylaufwerken überschreiben, aber Software, die selbst im CMOS nachschaut, sieht diese mauellen Parameter nicht.

    Laufwerksparameter sollte MS-DOS aber von vorneherein vom BIOS bekommen. das heißt, was du willst, kann nur funktionieren, wenn der PC trotz leerem CMOS korrekt von Festplatte booten kann. Und nach dem Neu setzen vom CMOS muss ein Reboot statt finden. Also bei einem PC mit IDE muss das BIOS die Festplatten per AUTO-Einstellung erkennen, oder der MFM/RLL/ESDI-Controller liest die Plattengeometrie aus den Daten, die er selbst per Lowlevel-Format auf die Platte geschrieben hat, oder es ist ein bootfähiger SCSI-Controller.

    Letzteres, also SCSI-Controller, das ist eine Lösung die ich da gerne verwende, meine Olivetti M380XP9 macht auch manchmal Zicken mit dem CMOS und liest es beim Systemstart nicht richtig aus, ein anderes Mal wiederum klappt es, keine Ahnung warum.

    Aber mit dem angehängten Tool, es ist unter GPL, habe ich mir da was gebastelt. Das Tool stammt aus dem Umfeld von FreeDos, vielleicht ist es dort sogar vorhanden. Bei mir läuft es problemlos z.B. unter MS-DOS 5. Das Tool kann das CMOS aus dem Chip in eine Datei auslesen, es kann eine Datei mit dem Chipinhalt vergleichen und zwei errorlevel (0=Ok, 7=verschieden) erzeugen, und es kann aus der Datei ins CMOS-RAM zurück schreiben, dann macht es einen Neustart, so dass MS-DOS beim Neustart die Laufwerke richtig übergeben bekommt.

    Damit habe ich mir dann eine kleine Batchdatei geschrieben, welche ich per call ganz am Anfang der autoexec.bat aufrufe. Das vergleicht den CMOS-Inhalt mit einer Datei, die ich mit dem Tool angelegt habe, und wenn der Errorlevel angibt, dass das nicht identisch ist, fragt die Batch nach date und time und schreibt anschließend den Inhat der gespeicherten CMOS-Datei wieder zurück in den Chip. Das funktioniert bisher problemlos.

    Der Inhalt kann nicht angezeigt werden, da du keine Berechtigung hast, diesen Inhalt zu sehen.

    Die Batchdatei zum abtippen, habe gerade kein USB-ZIP oder USB-Floppy zur Hand, um sie mal zu sichern... (benötigt cmos.com und be.exe (Batch Enhancer aus den Nortion Utilities))

    Außerdem kann man die Batch auch benutzen, um den aktuellen CMOS-Inhalt in die erforderliche Datei zu speichern. Das sollte man als erstes machen, wenn man die Batch benutzen will, und natürlich auch nach Einstellungsänderungen im BIOS. Dazu nach dem bei BIOS-Änderung erforderlichen Reboot an der Abfrage von Zeit bzw. Datum STRG+C drücken und dann die Batch mit dem Parameter "save" aufrufen. Das geht alles natürlich auch ohne die Batch, aber so muss ich mir die Syntax von cmos.com nicht zu merken oder wieder ansehen.

    Sehr schön, werde ich mal morgen ausprobieren...

    P.S.: Den passenden Assembler (a86) habe ich mal vorsorglich gleich mit heruntergeladen.

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey

    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.

    Einmal editiert, zuletzt von Peter z80.eu (22. November 2021 um 23:59)

    So richtig habe ich das Problem noch nicht verstanden. Ich hatte hier in den letzten Monaten einige Mainboards, wo die Pufferbatterie leer war.

    Ich gehe dann ins CMOS-Setup, stelle alles ein und mache dann einen Reset. Die meisten Setups starten sowieso neu, wenn man sie verlässt.

    Auch bei einem Hardware-Reset bleibt der Inhalt des CMOS-Setups erhalten. Erst wenn man die Spannung wegnimmt, sind die Daten weg.

    Also wo genau liegt das Problem das mit dem Programm behoben werden soll?

    Zitat von detlef

    Ich gehe dann ins CMOS-Setup, stelle alles ein und mache dann einen Reset.

    Vielleicht daran, dass dies "alles" doch nervig ist, insbesondere bei komplexen Einstellungen.

    Was ich nie probiert habe (da diese Dallas ja einfach verfügbar sind): mit zwei Dioden eine Backup Batterie und die System 5V an den VCC Pin des Dalles zu führen. Weiss allerdings nicht, wieviel Strom der dann zieht und was bei Abschalten des Systems alles schiefgeht, wenn Spannung da ist aber praktisch alle Leitungen gegen Masse gezogen werden, auch /CS, /WR usw...

    Zitat von detlef

    So richtig habe ich das Problem noch nicht verstanden. Ich hatte hier in den letzten Monaten einige Mainboards, wo die Pufferbatterie leer war.

    Ich gehe dann ins CMOS-Setup, stelle alles ein und mache dann einen Reset. Die meisten Setups starten sowieso neu, wenn man sie verlässt.

    Auch bei einem Hardware-Reset bleibt der Inhalt des CMOS-Setups erhalten. Erst wenn man die Spannung wegnimmt, sind die Daten weg.

    Also wo genau liegt das Problem das mit dem Programm behoben werden soll?

    Tja, genau so hätte ich mir das auch vorgestellt - ist es aber nicht. Mein Asus P55TP4XE meldet generell, also bei JEDEM Reset und auch bei Nutzung von Ctrl-Alt-Del, dass der Inhalt vom CMOS-RAM nicht korrekt ist, AUCH wenn ich den Rechner nicht ausschalte, das Mainboard also weiterhin unter Spannung steht.

    Und dummerweise natürlich damit auch, wenn ich ins BIOS Setup gehe, die richtigen Einstellungen (2 Diskettenlaufwerke, nicht eins !) vornehme, und abspeichern wähle, der Rechner nimmt wieder ein Kaltstart vor, und erzeugt wieder - wie beim Einschalten - eine Fehlermeldung, hat wieder die BIOS-Default Einstellungen. Gott sei Dank auch mit Festplatteneinstellung "Auto", so dass er bspw. von der Platte trotzdem booten kann.

    Daher hilft auch Reinhards + nichts, die Aussage bleibt, so ein Programm wie von 1ST1 ist damit hilfreich (gesetzt der Fall ich kriege es mit einem 2.ten Programm hin, den CMOS-RAM Inhalt zu manipulieren, ohne dass ein Reboot nötig ist).

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey

    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.

    Einmal editiert, zuletzt von Peter z80.eu (23. November 2021 um 08:32)

    Es gibt im Dallas natürlich ein Statusbit "Batterie schwach bzw. leer". Manche BIOSe werten das dann wohl aus :)

    Die Dallas-Chips haben ein "Valid RAM and time"-Statusbit (VRT), das nicht geschrieben, sondern nur gelesen werden kann. Sobald die Batterie leer ist, liefert dieses Bit immer eine 0, unabhängig davon, ob seit dem letzten Schreiben ins CMOS der Strom weg war oder nicht (also unabhängig davon, ob die Werte in RAM und Uhr gültig sind). Wenn das BIOS dieses Bit statt der CMOS-Checksumme auswertet und entsprechend auf Fallback-Werte zurückfällt, dann hilft ein reines Reboot nicht viel.

    Es ist allerdings nicht so, dass DOS seine Parameter direkt aus dem CMOS-RAM bezieht (weil das tierisch lahm ist) - Das macht das BIOS, und das Lesen wird i.A. nur einmal beim Booten ausgeführt und setzt dann die Daten im BIOS Variablenbereich (genaudasselbe passiert auch mit der Uhrzeit - Die wird auch nur einmal aus der Uhr gelesen und dann im Timer-Interrupt weitergesetzt). Und wie der interne Variablenbereich genau aussieht, weiß man i.A. nicht. Dürfte also eher schwierig werden.

    Dein Ansatz würde wohl funktionieren, wenn das BIOS vor jedem Festplattenzugriff in die Uhr schauen würde und den Festplattentyp neu bestimmen würde. Das ist aber halt nicht so, weil man Festplatten im laufenden Betrieb eher selten wechselt. Das BIOS schaut da einmal (beim Booten) rein und merkt sich das.

    Nochmal nachgeschaut: Das BIOS speichert die HD-Parameter-Tabelle für die erste Platte unter einem Zeiger, auf den der INT41h zeigt - Möglicherweise könnte man dort patchen und erreichen, was du möchtest.

    3 Mal editiert, zuletzt von tofro (23. November 2021 um 10:14)

    Zitat von Peter z80.eu

    tofro - Sollte es nicht einen BIOS Einsprungspunkt geben, wo die erste Prüfung von RAM und I/O usw. schon gelaufen ist ? Dann könnte dass doch noch klappen ...

    Hmm. Warum sollte es den geben? Das BIOS würde sich doch nur selber das Leben schwer machen, wenn es nicht weiß, was alles richtig oder falsch initialisiert ist.

    Ich würde mal versuchen, was passiert, wenn du die oben erwähnte INT41h-BIOS-HD-Parametertabelle patchst, sprich, ob du dann mit einer von DOS lesbaren Platte endest.

    Die Platte ist nicht das Problem (das BIOS hat, wie weiter oben bereits beschrieben, den Default Wert "Auto" bei der Plattenerkennung), es wäre das zweite Diskettenlaufwerk hauptsächlich das Problem....

    P.S.:

    Code
    ; -- Snippet -- ;
mov ax, 0x0040 ; AX = 0x0040
mov es, ax ; ES = AX
mov di, 0x0072 ; DI = 0x0072 (our offset is ES:DI)
mov ax, 0x1234 ; AX = 0x1234
stosw ; Put AX at ES:DI
jmp 0FFFFh:0000h ; Jump to reboot.

    Das (oder ähnlich) ist eigentlich eine Möglichkeit, einen "Warmboot" zu machen, wo bspw. der Speichertest übersprungen wird (wegen des Hex Werts 1234 an besagter Speicherstelle).

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey

    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.

    Nachtrag: Wenn es nur um das nicht erkannte Diskettenlaufwerk geht, und sonst um nichts, könnte ich vielleicht auch das hier machen:

    DRIVPARM=/D:1 /C /F:2 /H:2 /S:15 /T:80 (geht bis einschließlich MS-DOS 7.1)

    oder

    DEVICE=DRIVER.SYS /D:1 /C /F:1 /H:2 /S:15 /T:80 (geht eigentlich nur bis MS-DOS 6.22, es sei denn man patcht die Versionsabfrage weg)

    Habe ich aber noch nicht ausprobiert, ob das trotz falschem Wert im CMOS-RAM (vom BIOS also nicht verwaltet) geht.

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey

    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.

    Hmmm.... muss ich mal schauen, ob ich das mit SOFTICE (ein sehr guter Debugger !) schauen kann, ob da eine Abfrage im DRIVER.SYS selbst ist, und ob man die wegpatchen kann. Ich habe aber auch im Internet den Hinweis gefunden, dass UNIFORM (eigentlich eher für CP/M Formate gedacht, kann aber auch MS-DOS Formate) so was erlauben soll, d.h. auch nicht vom BIOS vorhandene Laufwerke bereitstellen kann.

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey

    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.

    Ok, segor.de hat doch (ohne weitere Ankündigung) heute meine bestellten Teile geliefert, unter anderem ein DS12887+ ... habe aber, warum auch immer, den Sockel vergessen zu bestellen :( Muss ich wohl noch nachholen.

    Was die Versuche angeht, auch ohne Austausch weiterzukommen - weder der Treiber für den Sunix Controller (Meldung: Es wird keine Sunix Karte gefunden) noch der gepatchte DRIVER.SYS (der wird geladen, aber zeigt sehr merkwürdige Daten für das Laufwerk an, wenn man MSD aufruft, und das Laufwerk kann nicht angesprochen werden) brachten Erfolg. Könnte sein, dass DRIVER.SYS den BiosParameterHeader sich wieder holt, d.h. irgendwelche zufälligen Werte.

    Das Abspeichern des CMOS-RAM hat zwar funktioniert, aber selbst wenn ich die so generierte Datei an der richtigen Stelle manipuliere, führt das Programm nach dem Laden des CMOS Inhalts trotzdem ein Reboot aus (nicht weil es fehlerhaft ist, sondern weil das so vorgesehen ist). Und beim Reboot ist wieder alles beim Alten, die BIOS Default Werte werden geladen.

    Hat also alles kein Zweck.

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey

    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.

    Ok, ein letztes Update, habe eine Lösung gefunden, die wahrscheinlich recht unkonventionell ist.

    Mit Hilfe von MODBIN (in dem Fall die Version 4.50.80C) habe ich mein ASUS P55TP4XE BIOS verändert, und zwar genau an der Stelle, wo im 2. Bild das Feld hervorgehoben ist (Drive B, Setup Default). Dann habe ich es erstmal mit 86box getestet, da gibt es genau die Maschine mit genau dem BIOS auch, einfach die Datei ausgetauscht und gebootet. Hat funktioniert, also auch den echten Rechner geflasht. Und voilà, ich kann das Laufwerk B: - weil jetzt der BIOS Default passt - benutzen, auch ohne korrektes CMOS-RAM. Kommt der Prophet nicht zum Berg, muss der Berg zum Propheten :)