1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen

HowTo Firmwareupdate

Dieses Thema im Forum "Raspberry Pi" wurde erstellt von Kermit, 18. Dezember 2012.

  1. Kermit
    Online

    Kermit Guest

    Hi,

    wer nicht immer ein neues Image auf seine SD Karte schreiben möchte kann auch den Kernel bzw die Firmware des Raspberry manuell aktuallisieren.

    Hierzu wird das Tool rpi-update von Hexxeh benötigt.

    Damit wir an das Tool selber kommen sind drei Schritte notwendig.

    Als erstes benötigen wir git-core. Was ist git-core?
    Git Grundlagen

    Was also ist Git, in kurzen Worten? Es ist wichtig, den folgenden Abschnitt zu verstehen, in dem es um die grundlegenden Konzepte von Git geht. Das wird dich in die Lage versetzen, Git einfacher und effektiver anzuwenden. Versuche dein vorhandenes Wissen über andere Versionskontrollsysteme, wie Subversion oder Perforce, zu ignorieren, während Du Git lernst. Git speichert und konzipiert Information anders als andere Systeme, auch wenn das Interface relativ ähnlich wirkt. Diese Unterschiede zu verstehen wird dir helfen, Verwirrung bei der Anwendung von Git zu vermeiden.

    Der Hauptunterschied zwischen Git und anderen Versionskontrollsystemen (auch Subversion und vergleichbaren Systemen) besteht in der Art und Weise wie Git Daten betrachtet. Die meisten anderen Systeme speichern Information als eine fortlaufende Liste von Änderungen an Dateien ("Diffs"). Diese Systeme (CVS, Subversion, Perforce, Bazaar usw.) betrachten die Informationen, die sie verwalten, als eine Menge von Dateien und die Änderungen, die über die Zeit hinweg an einzelnen Dateien vorgenommen werden. (Siehe Bild 1-4.)
    [​IMG]
    Bild 1-4. Andere Systeme speichern Daten als Änderungen an einzelnen Dateien einer Datenbasis Git sieht Daten nicht in dieser Weise. Stattdessen betrachtet Git seine Daten eher als eine Reihe von Snapshots eines Mini-Dateisystems. Jedes Mal, wenn Du committest (d.h. den gegenwärtigen Status deines Projektes als eine Version in Git speicherst), sichert Git den Zustand sämtlicher Dateien in diesem Moment ("Snapshot") und speichert eine Referenz auf diesen Snapshot. Um dies möglichst effizient und schnell tun zu können, kopiert Git unveränderte Dateien nicht, sondern legt lediglich eine Verknüpfung zu der vorherigen Version der Datei an. Git betrachtet Daten also wie in Bild 1-5 dargestellt.
    [​IMG]
    Bild 1-5. Git speichert Daten als eine Historie von Snapshots des Projektes. Dies ist ein wichtiger Unterschied zwischen Git und praktisch allen anderen Versionskontrollsystemen. In Git wurden daher fast alle Aspekte der Versionskontrolle neu überdacht, die in anderen Systemen mehr oder weniger von ihren jeweiligen Vorgängergeneration übernommen worden waren. Git arbeitet im Großen und Ganzen eher wie ein (mit einigen unglaublich mächtigen Werkezeugen ausgerüstetes) Mini-Dateisystem, als wie ein gängiges Versionskontrollsystem. Auf einige der Vorteile, die es mit sich bringt, Daten in dieser Weise zu betrachten, werden wir in Kapitel 3 eingehen, wenn wir das Git Branching Konzept diskutieren.

    Die meisten Operationen in Git benötigen nur die lokalen Dateien und Ressourcen auf deinem Rechner, um zu funktionieren. D.h. im Allgemeinen werden keine Informationen von einem anderen Rechner im Netzwerk benötigt. Wenn Du mit einem CVCS gearbeitet hast, das für die meisten Operationen einen Netzwerk Latency Overhead (also Wartezeiten, die das Netzwerk benötigt werden) hat, dann wirst Du den Eindruck haben, dass die Götter der Geschwindigkeit Git mit unaussprechlichen Fähigkeiten ausgestattet haben. Weil man die vollständige Historie lokal auf dem Rechner hat, werden die allermeisten Operationen ohne jede Verzögerung ausgeführt und sind sehr schnell.
    Um beispielsweise die Historie des Projektes zu durchsuchen, braucht Git sie nicht von einem externen Server zu holen - es liest sie einfach aus der lokalen Datenbank. Das heißt, Du siehst die vollständige Projekthistorie ohne jede Verzögerung. Wenn Du sehen willst, worin sich die aktuelle Version einer Datei von einer Version von vor einem Monat unterscheidet, dann kann Git diese Versionen lokal nachschlagen und ihre Unterschiede lokal bestimmen. Es braucht dazu keinen externen Server - weder um Dateien dort nachzuschlagen, noch um Unterschiede dort bestimmen zu lassen.
    Dies bedeutet natürlich außerdem, dass es fast nichts gibt, was Du nicht tun kannst, bloß weil Du gerade offline bist oder keinen Zugriff auf ein VPN hast. Wenn Du im Flugzeug oder Zug ein wenig arbeiten willst, kannst Du problemlos deine Arbeit committen und deine Arbeit erst auf den Server pushen (hochladen), wenn Du wieder mit einem Netzwerk verbunden bist. Wenn Du zu Hause bist aber nicht auf das VPN zugreifen kannst, kannst Du dennoch arbeiten. Perforce z.B. erlaubt dir dagegen nicht sonderlich viel zu tun, solange Du nicht mit dem Server verbunden bist. Und in Subversion und CVS kannst Du Dateien zwar ändern, die Änderungen aber nicht in der Datenbank sichern (weil die Datenbank offline ist). Das mag auf den ersten Blick nicht nach einem großen Problem aussehen, aber Du wirst überrascht sein, was für einen großen Unterschied das ausmachen kann.

    In Git werden Änderungen in Checksummen umgerechnet, bevor sie gespeichert werden. Anschließend werden sie mit dieser Checksumme referenziert. Das macht es unmöglich, dass sich die Inhalte von Dateien oder Verzeichnissen ändern, ohne dass Git das mitbekommt. Git basiert auf dieser Funktionalität und sie ist ein integraler Teil von Gits Philosophie. Man kann Informationen deshalb z.B. nicht während der Übermittlung verlieren oder unwissentlich beschädigte Dateien verwenden, ohne dass Git in der Lage wäre, dies festzustellen.
    Der Mechanismus, den Git verwendet, um diese Checksummen zu erstellen, heißt SHA-1 Hash. Eine solche Checksumme ist eine 40 Zeichen lange Zeichenkette, die aus hexadezimalen Zeichen besteht und diese wird von Git aus den Inhalten einer Datei oder Verzeichnisstruktur kalkuliert. Ein SHA-1 Hash sieht wie folgt aus:

    24b9da6552252987aa493b52f8696cd6d3b00373 Dir werden solche Hash Werte überall in Git begegnen, weil es sie so ausgiebig benutzt. Tatsächlich speichert und referenziert Git Informationen über Dateien in der Datenbank nicht nach ihren Dateinamen sondern nach den Hash Werten ihrer Inhalte.

    Fast alle Operationen, die Du in der täglichen Arbeit mit Git verwendest, fügen Daten jeweils nur zur internen Git Datenbank hinzu. Deshalb ist es sehr schwer, das System dazu zu bewegen, irgendetwas zu tun, das nicht wieder rückgängig zu machen ist, oder dazu, Daten in irgendeiner Form zu löschen. In jedem anderen VCS ist es leicht, Änderungen, die man noch nicht gespeichert hat, zu verlieren oder unbrauchbar zu machen. In Git dagegen ist es schwierig, einen einmal gespeicherten Snapshot zu verlieren, insbesondere wenn man regelmäßig in ein anderes Repository pusht.
    U.a. deshalb macht es so viel Spaß, mit Git zu arbeiten. Man kann mit Änderungen experimentieren, ohne befürchten zu müssen, irgendetwas zu zerstören oder durcheinander zu bringen. Einen tieferen Einblick in die Art, wie Git Daten speichert und wie man Daten, die scheinbar verloren sind, wieder herstellen kann, wird Kapitel 9 gewähren.

    Jetzt aufgepasst. Es folgt die wichtigste Information, die Du dir merken mußt, wenn Du Git lernen und Fallstricke vermeiden willst. Git definiert drei Haupt-Zustände, in denen sich eine Datei befinden kann: committed, modified ("geändert") und staged ("vorgemerkt"). "Committed" bedeutet, dass die Daten in der lokalen Datenbank gesichert sind. "Modified" bedeutet, dass die Datei geändert, diese Änderung aber noch nicht committed wurde. "Staged" bedeutet, dass Du eine geänderte Datei in ihrem gegenwärtigen Zustand für den nächsten Commit vorgemerkt hast.
    Das führt uns zu den drei Hauptbereichen eines Git Projektes: das Git Verzeichnis, das Arbeitsverzeichnis und die Staging Area.
    [​IMG]
    Bild 1-6. Arbeitsverzeichnis, Staging Area (xxx) und Git Verzeichnis Das Git Verzeichnis ist der Ort, an dem Git Metadaten und die lokale Datenbank für dein Projekt speichert. Dies ist der wichtigste Teil von Git, und dieser Teil wird kopiert, wenn Du ein Repository von einem anderen Rechner klonst.
    Dein Arbeitsverzeichnis ist ein Checkout ("Abbild" xxx) einer spezifischen Version des Projektes. Diese Dateien werden aus der komprimierten Datenbank geholt und auf der Festplatte in einer Form gespeichert, die Du bearbeiten und modifizieren kannst.
    Die Staging Area ist einfach eine Datei (normalerweise im Git Verzeichnis), in der vorgemerkt wird, welche Änderungen dein nächster Commit umfassen soll. Sie wird manchmal auch als "Index" bezeichnet, aber der Begriff "Staging Area" ist der gängigere.
    Der grundlegend Git Arbeitsprozess sieht in etwa so aus:

    1. Du bearbeitest Dateien in deinem Arbeitsverzeichnis.
    2. Du markierst Dateien für den nächsten Commit, indem Du Snapshots zur Staging Area hinzufügst.
    3. Du legst den Commit an, wodurch die in der Staging Area vorgemerkten Snapshots dauerhaft im Git Verzeichnis (d.h. der lokalen Datenbank) gespeichert werden.
    Wenn eine bestimmte Version einer Datei im Git Verzeichnis liegt, gilt sie als "committed". Wenn sie geändert und in der Staging Area vorgemerkt ist, gilt sie als "staged". Und wenn sie geändert, aber noch nicht zur Staging Area hinzugefügt wurde, gilt sie als "modified". In Kapitel 2 wirst Du mehr über diese Zustände lernen und darüber, wie Du sie sinnvoll einsetzen und wie Du den Zwischenschritt der Staging Area auch einfach überspringen kannst.
    Wir installieren es uns mit Hilfe des Befehls
    Code:
    sudo apt-get install git-core
    
    Als zweites benötigen wir die passenden Zertifikate, was mit
    Code:
    sudo apt-get install ca-certificates
    
    erledigt sein sollte. Anschließend laden wir das Tool selber herunter, speichern es an der passende Stelle ab und vergeben auch gleich noch die richtigen Rechte:
    Code:
    sudo wget http://goo.gl/1BOfJ -O /usr/bin/rpi-update && sudo chmod +x /usr/bin/rpi-update
    
    Sobald die Installation abgeschlossen ist, kann mit einem
    Code:
    sudo rpi-update
    
    der Aktuallisierungsprozess angestoßen werden. Hierbei sollte ein klein wenig Zeit eingeplant werden.
    Solange der kernel aktuell ist beendet sich das Tool mit dem Hinweis
    Code:
    root@raspberrypi:~# rpi-update
    Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS
    Performing self-update
    ARM/GPU split is now defined in /boot/config.txt using the gpu_mem option!
    Updating firmware (this will take a few minutes)
    Your firmware is already up to date
    
    Ansonsten kommt ein Hinweis, dass der Raspberry neu gebootet werden muß um den neuen Kernel zu verwenden.

    In der Hoffnung etwas Licht ins Dunkel gebracht zu haben

    Kermit

     
    #1
  2. phantom

    Nervigen User Advertisement

  3. Oller
    Offline

    Oller Ist gelegentlich hier

    Registriert:
    15. Mai 2008
    Beiträge:
    88
    Zustimmungen:
    29
    Punkte für Erfolge:
    18
    AW: Firmwareupdate

    Sicherheitshalber würde ich da noch als erstes "sudo apt-get update" empfehlen. Nur um sicher zu gehen dass beim "sudo apt-get install" auch die aktuellen packages installiert werden.
     
    #2
  4. marmet45
    Offline

    marmet45 Ist gelegentlich hier

    Registriert:
    3. November 2009
    Beiträge:
    39
    Zustimmungen:
    1
    Punkte für Erfolge:
    8
    AW: Firmwareupdate

    Hab das mal probiert.
    Nach "Updating firmware (this will take a few minutes)" passiert nix mehr.
    Hab 70 min gewartet. strg-c bricht normal ab.
    cat /proc/version liefert: Linux version 3.2.27+ (dc4@dc4-arm-01) (gcc version 4.7.2 20120731 (prerelease) (crosstool-NG linaro-1.13.1+bzr2458 - Linaro GCC 2012.08) ) #307 PREEMPT Mon Nov 26 23:22:29 GMT 2012

    Der Pi funzt ja prima, so dass ich nicht unbedingt ein update brauche, aber wundern tut es mich schon, dass da gar keine Reaktion kommt.

    Eine Idee??
     
    #3
  5. aragorn
    Online

    aragorn Guest

    AW: Firmwareupdate

    warte einfach mal ein bischen, das kann in einzelnen fällen leider durchaus 1-2 stunden dauern, jenachdem wieviele dateien er laden muss und wie sehr der quellserver ausgelastet ist (deine eigene internetgeschwindigkeit spielt dabei aber natürlich auch ne rolle aber eben nicht nur)
     
    #4
  6. marmet45
    Offline

    marmet45 Ist gelegentlich hier

    Registriert:
    3. November 2009
    Beiträge:
    39
    Zustimmungen:
    1
    Punkte für Erfolge:
    8
    AW: Firmwareupdate

    1-2h? Wow, dann lass ich ihn noch mal laufen. Blöd, dass man nicht irgendeinen Status sehen kann. I-net ist nun wirklich nicht langsam bei mir, aber vllt ja auf der anderen Seite.
    Bin mal gespannt. Den Pi lasse ich eh an. Mal gucken, ob sich was tut. Danke schon mal.

    EDIT: nach bisher 2 Stunden noch nix. Bin weiterhin gespannt.

    EDIT#2: scheint auch anderen so zu gehen. Offensichtlich wird, wenn die neueste Firm bereits installiert ist (könnte bei mir der Fall sein) nicht abgebrochen (siehe

    Dieser Link ist nur für Mitglieder!!! Jetzt kostenlos Registrieren ?

    )
     
    Zuletzt bearbeitet: 28. Dezember 2012
    #5
    1 Person gefällt das.
  7. Kermit
    Online

    Kermit Guest

    AW: Firmwareupdate

    Hi,

    es gibt einen neuen Kernel.
    uname -a sagt
    Code:
    root@raspberrypi:~# uname -a
    Linux raspberrypi 3.6.11+ #346 PREEMPT Fri Dec 28 00:50:33 GMT 2012 armv6l GNU/Linux
    
    Grüße

    Kermit
     
    #6
  8. aragorn
    Online

    aragorn Guest

    AW: Firmwareupdate

    dort im letzten post steht der fix:
    danach wie gewohnt " rpi-update " ausführen
     
    #7
  9. chrisbi
    Offline

    chrisbi Hacker

    Registriert:
    29. Januar 2008
    Beiträge:
    326
    Zustimmungen:
    195
    Punkte für Erfolge:
    43
    AW: Firmwareupdate

    Hat vielleicht jemand ne Quelle für nen changelog?

    Würde mich mal interessieren...

    Edit: hab sowas änliches selbst gefunden hier:

    Dieser Link ist nur für Mitglieder!!! Jetzt kostenlos Registrieren ?



    Hier stehn die changes...
     
    Zuletzt bearbeitet: 31. Dezember 2012
    #8
    2 Person(en) gefällt das.
  10. marmet45
    Offline

    marmet45 Ist gelegentlich hier

    Registriert:
    3. November 2009
    Beiträge:
    39
    Zustimmungen:
    1
    Punkte für Erfolge:
    8
    AW: Firmwareupdate

    hatte ich gemacht... kein unterschied. naja, bin ich eben etwas weniger aggressiv mit firm-updates.
     
    #9
  11. Kermit
    Online

    Kermit Guest

    AW: Firmwareupdate

    Hi,

    ich hab gestern mal wieder ein
    Code:
    apt-get update
    apt-get upgrade
    rpi-update
    
    durchgeführt und inzwischen wird auch bei rpi-update fein säuberlich angezeigt was das System macht.

    Grüße

    Kermit

    P.S.: Seit dem 01.01.13 gibt es wieder einen neuen Kernel.
     
    #10
  12. aragorn
    Online

    aragorn Guest

    AW: Firmwareupdate

    die ersten beiden (rot markierten) zeile sind für "rpi-update" eigentlich überflüssig/unnötig da das "rpi-update" script keine apt-pakete herrunter läd sondern seine dateien alle über git bezieht

    das rpi-update script wurde am 31.12.2012 aktualisiert und updatet sich seitdem selber, wer also das script noch nicht geupdatet hat, sollte das mal machen - alle anderen die bereits das neue script haben brauchen sich darum künftig nicht mehr kümmern
     
    #11
  13. Kermit
    Online

    Kermit Guest

    AW: Firmwareupdate

    Hi,

    da hast du recht. Ich hole mir in dem Zusammenhang halt immer die aktuellen Pakete gleich mit, da es sich ja nicht um eine stable Variante von Debian handelt. Auf der anderen Seite kannst du jetzt sagen (hast auch recht damit) die neuen Pakete müssen nicht zwangsläufig besser sein.

    Grüße

    Kermit
     
    #12
  14. tztztz
    Offline

    tztztz Ist oft hier

    Registriert:
    14. Februar 2009
    Beiträge:
    103
    Zustimmungen:
    24
    Punkte für Erfolge:
    18
    AW: Firmwareupdate

    MoinMoin,

    leider bringt mir das Firmwareupdate mit "rpi-update" nur Fehlermeldungen...

    hier ein kleiner Auszug:


    Woran liegt´s?

    MfG
     
    #13
  15. aragorn
    Online

    aragorn Guest

    AW: Firmwareupdate

    am schlechten wetter...



    ohne genauere infos, welchen kernel du zzt hast oder welche rpi-update version du hast usw kann man da vermutlich nur wild drauf los raten
     
    #14
  16. tztztz
    Offline

    tztztz Ist oft hier

    Registriert:
    14. Februar 2009
    Beiträge:
    103
    Zustimmungen:
    24
    Punkte für Erfolge:
    18
    AW: Firmwareupdate

    Wenn du mir bitte schreiben könntest wie ich Kernel & rpi-update Version angezeigt bekomme dann gebe ich dir gern die Daten.
     
    #15

Diese Seite empfehlen