Ankündigung: 256bytes Support in nvram-wakeup!!!

    Zitat

    Original von Bistr-o-Math
    ... dann kompillier es doch bitte und lass das angegebene Kommando laufen.


    Bitte schön:

    Zitat

    Original von Rainer_HB

    Vielen Dank!


    wenigstens wissen wir nun, dass diese Methode bei dem VT8235 nicht zu funktionieren scheint.

    Hi,


    nur zur Info,


    Zitat

    wenigstens wissen wir nun, dass diese Methode bei dem VT8235 nicht zu funktionieren scheint.


    beim EPIA-800 ist es das selbe der Upperbereich ist durchweg 0 und guess findet keine Differenzen zwischen den Weckzeiten.




    CU,
    Andreas

    Zitat

    Original von Hulk


    beim EPIA-800 ist es das selbe der Upperbereich ist durchweg 0 und guess findet keine Differenzen zwischen den Weckzeiten.


    Code
    #> lspci
...
00:11.4 Bridge: VIA Technologies, Inc. VT8235 ACPI (rev 10)


    fuer den VT8235 sind von VIA keine datasheets zu bekommen :(


    du kannst natuerlich auch mal "auf gut Glueck" die beiden anderen Methoden ausprobieren.

    Hi,


    Zitat

    fuer den VT8235 sind von VIA keine datasheets zu bekommen


    da die Informationen wohl nur per NDA verfügbar sind, wird es wohl ein Wunschtraum bleiben.
    Aber per "settimer"Script läuft's ja, mal von ein paar kleinen Seiteneffekte abgesehen.


    Hmm, zum "Apollo PLE133 Chipset VT8601A North Bridge" konnte ich einen offizlelles Datasheet finden. http://www.viavpsd.com/product/6/15/DS8601A182.pdf


    CU,
    Andreas

    Zitat

    Original von Hulk
    Hi,



    da die Informationen wohl nur per NDA verfügbar sind, wird es wohl ein Wunschtraum bleiben.
    ...


    Hmm, zum "Apollo PLE133 Chipset VT8601A North Bridge" konnte ich einen offizlelles Datasheet finden.


    leider bringt das nichts. Die CMOS/RTC geschichte haengt von der south bridge ab.
    (bei dem PLE133 war das laut Seite 7 von der PDF-Datei der VT82C686B)

    Hallo !


    Wollte mal fragen ob das schon jemand mit dem nForce2 Chipsatz probiert hat?
    und ob es überhaupt gehen würde!


    Hab mir das Asus A7VNX-E Deluxe gekauft und werde das mal checken.


    Geht NvRam da überhaupt! Hab gesehen die haben nur Einstellungen für Stunde, Minute und Sekunde ???




    Gruß Denny

    VDR-CLIENT: Asrock Q1900-ITX, 2GB RAM, OCZ Agility 3 60GB, OpenElec-XMBC XVDR (UEFI 18sek Bootzeit)

    VDR-CLIENT: Raspberry-Pi mit OpenElec und XVDR Plugin

    VDR-SERVER: HP MicroServer N54, 8GB Ram, BiosMod, 12TB HDD, XenServer mit Ubuntu Server VM als VDR-Server, C2


    Zitat

    fuer den VT8235 sind von VIA keine datasheets zu bekommen


    Was ich nicht verstehe: Warum funktionieren die EPIA-M mit nvram-wakeup? Die haben doch auch die VIA VT8235-SB?!

    Zitat

    Original von Terminator


    Was ich nicht verstehe: Warum funktionieren die EPIA-M mit nvram-wakeup? Die haben doch auch die VIA VT8235-SB?!


    solange alle Einstellungen innerhalb der unteren 128 bytes gespeichert sind, ist
    die Methode zum auslesen/beschreiben durch den ISA Standard festgelegt und
    unabhaengig von chipsaetzen/Herstellern.


    Die heutigen boards haben alle mindestens (gibt es auch welche mit mehr?) 256 bytes
    nvram. Die Methode fuer den Zugriff auf die oberen 128 bytes ist abhaengig vom Hersteller
    oder dem Chipsatz. D.h. wenn die Wakeup-Einstellungen in diesem oberen nvram
    gespeichert sind, haengt es davon ab, welcher Chipsatz installiert ist, ob man diese
    Einstellungen auslesen kann oder nicht.


    das kannst du ausprobieren. Wenn die Einstellungen im unteren nvram liegen, ist es wie gesagt, unabhaengig vom Chipsatz.


    Zitat

    Hab gesehen die haben nur Einstellungen für Stunde, Minute und Sekunde ???


    das waere an und fuer sich kein Problem. Wenn du halt den naechsten Timer erst in 10 Tagen um 20:15 hast, wird der Redchner jeden Tag um 20:10 aufwachen und feststellen, dass kein Timer ansteht und dann nach MinUserInactivity Minuten wieder runterfahren.
    Bis der Tag kommt, an dem der Timer tatsaechlich was aufnimmt.

    Jetzt brauch ich mir doch kein externes Hardware-Board zu bauen!!
    Super, Danke !!!!!!!!!!!!!!!!!!


    Hab ein abgedrehtes IBM-Board (PC 300PL)
    mit South Bridge VIA vt82c596b


    guess ist verzweifelt weil es keine checksumme gab und einige werte zweimal drinstanden.
    Habs selber "gehackt" und mein Config funktioniert:



    leider ist der bcd-code ziemlich "kaputt" .....
    deswegen noch


    Code
    nr_date     = 8
nr_min      = 8
nr_hour     = 8


    wäre als default bei bcd nicht schlecht... zumindest hätte es mir einiges an debugging gespart, wenn bcd = ON
    die nr_* automatisch auf vernünftige werte setzen würde ...


    also sehe ich das richtig, Checksumme gibt es gar nicht?


    Zitat
    Code
    nr_date     = 8
nr_min      = 8
nr_hour     = 8


    reichen vielleicht auch diese Werte?

    Code
    nr_date     = 6
                 nr_hour     = 6
                 nr_min      = 7

    jepp, sekunde gibts nicht, checksum ist auch nicht.
    im bios kann man alternativ auch wochentag bzw. täglich einstellen, aber das braucht man für vdr ja nicht...


    checksum ist auch nicht, und

    Code
    nr_date     = 6
nr_hour     = 6
nr_min      = 7


    würde wohl wahrscheinlich auch funktionieren, der Unterschied ist halt dann nur das die 0-bits beibehalten und nicht erzwungen werden würden, da alles andere aber eh quatsch wäre bzw. illegales bcd ...

    Hallo,


    nachdem mein ASUS-CUWE wohl auch eines der Kandidaten ist,
    welche das Datum hinter die 128 Byte-Grenze ablegen, wollte
    ich mal mein Glück mit der 256 Byte Version versuchen bevor
    ich wieder irgendwie am Kernel rumpatche.


    Habe also mit

    Code
    ./cat_nvram INTEL


    die vier Files erzeugt und dann guess darauf losgelassen.
    Das Ergebnis war folgendes (komplett siehe Anlage):



    Vor der Neuinstallation hatte ich es mit der Config vom CUWE-RM
    und Kernel patchen versucht. Damit hat das aufwecken zwar
    wunderbar funktioniert :] - nur leider ist beim Kernel kompilieren
    wohl etwas schiefgegangen und das System hatte einige Macken. ;(


    Kann man mit den Ausgaben was anfangen?
    Mir helfen sie leider nicht wirklich weiter. :(


    Ansonsten muss ich wohl doch wieder patchen.
    Kann man auch nur das NVRAM-Modul patchen
    (habe Suse 9.0) - wenn ja wie?


    Danke im voraus!

    Zitat

    Original von techno
    Hallo,


    nachdem mein ASUS-CUWE wohl auch eines der Kandidaten ist,
    welche das Datum hinter die 128 Byte-Grenze ablegen, wollte
    ich mal mein Glück mit der 256 Byte Version versuchen bevor
    ich wieder irgendwie am Kernel rumpatche.


    nein, bei dir liegt alles innerhalb der unteren 128 bytes.


    Zitat

    Vor der Neuinstallation hatte ich es mit der Config vom CUWE-RM
    und Kernel patchen versucht. ...


    die kannst du auch weiterhin nehmen. (ich fuege dein board in die CVS ein)
    statt kernel patchen kannst du auch --directisa nehmen.
    Allerdings ist --directisa im allgemeinen mit Vorsicht zu geniessen.


    Zitat

    Kann man auch nur das NVRAM-Modul patchen


    klar. der gleiche patch und dann 'make modules'

    Zitat

    nein, bei dir liegt alles innerhalb der unteren 128 bytes.


    Da war zumindest die 'normale' nvram-wakeup-Version
    anderer Meinung. Die meldet nämlich:

    Code
    rtc_date (0x7F) is beyond the end of nvram


    und nach dem patchen hatte es damals funktioniert.


    Wenn ich

    Code
    nvram-wakeup --directisa


    mache (nachdem ich in der nvram-wakeup-mb.c
    das CUWE-RM in CUWE geändert habe)


    zeigt es mir als rtcDate 00 (0x80)
    wobei es doch eigentlich 0x7F sein sollte


    Außerdem stimmt auch der Inhalt nicht,
    weil vom letzten guess Eintrag sollte
    ja eigentlich auch 01 und nicht 00 im Datum stehen.


    Kann ich beim Modul patchen irgendwie auch nur das NVRAM-Modul angeben?
    Bei make Modules will er doch bestimmt alle Module maken - oder?

    Zitat

    Original von techno


    Da war zumindest die 'normale' nvram-wakeup-Version
    anderer Meinung. Die meldet nämlich:

    Code
    rtc_date (0x7F) is beyond the end of nvram


    weil das Standard nvram-modul nur 114 bytes enthaelt. checkst du z.B. so:

    Code
    # wc -c /dev/nvram
    114 /dev/nvram


    Zitat

    und nach dem patchen hatte es damals funktioniert.


    weil der Patch die restlichen 14 bytes freigibt. Die sind normalerweise aus bestimmten
    Gruenden einfach wegmaskiert.
    Mit den ueber 128bytes liegendem nvram verhaelt es sich ganz anders:
    da ist es Hersteller-abhaengig und teilweise nicht bekannt.


    Zitat

    Wenn ich

    Code
    nvram-wakeup --directisa


    mache (nachdem ich in der nvram-wakeup-mb.c
    das CUWE-RM in CUWE geändert habe)


    zeigt es mir als rtcDate 00 (0x80)
    wobei es doch eigentlich 0x7F sein sollte


    0x80 an dieser Stelle ist nicht die Adresse sondern der Inhalt vom ganzen byte,
    wobei das Datum nicht alle bits davon belegt.


    Zitat

    Außerdem stimmt auch der Inhalt nicht,
    weil vom letzten guess Eintrag sollte
    ja eigentlich auch 01 und nicht 00 im Datum stehen.


    dein Board schreibt 00 ins Datum wenn der Wakeup ausgeschaltet wird.
    (daher auch die Zeile reset_date in der Konfiguration)


    Zitat

    Kann ich beim Modul patchen irgendwie auch nur das NVRAM-Modul angeben?
    Bei make Modules will er doch bestimmt alle Module maken - oder?


    ja. aber nur die, bei denen sich die Sourcen seit dem letzten maken geaendert haben.
    allerdings laeuft er ueber alle module und checkt, ob sich was geaendert hat.


    Wenn du allerdings noch nie von deinen sourcen was kompilliert hast, dann wird er alle
    Module neu kompillieren.

    Zitat

    Original von Bistr-o-Math



    dein Board schreibt 00 ins Datum wenn der Wakeup ausgeschaltet wird.
    (daher auch die Zeile reset_date in der Konfiguration)



    PS.: Geh doch mal ins BIOS und gib ein paar Werte ein (Wakeup eingeschaltet)
    dann lass mal nvram-wakeup --directisa laufen.

    Zitat

    Original von Bistr-o-Math
    PS.: Geh doch mal ins BIOS und gib ein paar Werte ein (Wakeup eingeschaltet)
    dann lass mal nvram-wakeup --directisa laufen.


    :doof


    Hatte ich gerade gemacht - bevor ich deine Antworten gelesen habe.
    (konnte ja nicht ahnen, dass du so prompt antwortest 8o)
    Da ist es mir dann auch mit dem rtc_Date klar geworden, weil da plötzlich 0x91 drinnen stand als ich 11 als Datum eingetragen habe.


    Da mir die Werte zugesagt haben, hab ich dann --directisa
    ausprobiert - und es funktioniert. :]


    Was würdest du mir raten - soll ich bei directisa bleiben
    oder es doch lieber patchen?


    Auf jeden Fall schon mal Dankeschön für deine prompte Hilfe!

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden