Ich hatte ähnliche Probleme und habe diese letzte Nacht unter OS X 10.8.5 mit QEMU v2.2.0 endlich zum Laufen gebracht , nachdem ich zwei Wochen lang ein- und ausgeschaltet hatte.
Präambel
Ich wurde von der Frage gefragt, ob ich für Arduino programmieren kann, ohne ein echtes Board zu haben. , um zu versuchen, einen echten Emulator wie QEMU zu verwenden , wie von zmo vorgeschlagen , in einem Kommentar zu Anindo Ghoshs Antwort.
Ich dachte, ich würde meine Erfahrungen hier erzählen.
Ich habe dies auf einem MacBook Pro mit 10.8 eingerichtet. (Berglöwe). Ich fand schnell den Link Installieren von QEMU unter OS X 1 . Ja, ich weiß, es scheint mit dem Pi verwandt zu sein, aber ertrage es mit mir. Nach einem kurzen Stöbern war klar, was erforderlich war.
Der erste Schritt bestand darin, den Mac mit der richtigen Umgebung einzurichten. Dies erforderte in der folgenden Reihenfolge:
- Xcode;
- Xcode-Befehlszeilentools;
- Homebrew;
- ein Compiler und schließlich;
- Qemu selbst
Einzelheiten
Auf jeden Schritt im Detail eingehen
- Xcode - Ich habe 5.1 von der Apple-Website verwendet [Link?]
- Die Befehlszeilentools wurden aus Xcode unter Tools -> Downloads heruntergeladen.
- Homebrew wurde mit dem folgenden Befehl im Terminal installiert
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Zunächst war der Download fehlgeschlagen, da das thailändische Telefonnetz ausfiel und eine unordentliche Bereinigung erforderlich war. Aber das erneute Ausführen des Befehls hat funktioniert.
- Dann
brew doctor
, als ich mich zuerst beschwerte, dass ich ein Dateisystem mit Groß- und Kleinschreibung habe , stellte ich eine Anforderung für Quartz 2.7.7 auf , ich hatte offensichtlich 2.7.4 installiert. Dies habe ich heruntergeladen, neu gestartet,
brew doctor
wieder ausgeführt. Es beschwerte sich immer noch, aber diesmal, weil ich Quartz 2.6.3 installiert hatte! Ich gab an diesem Punkt auf und ging weiter.
- Für die Auswahl des QEMU-Builds sind diese beiden Befehle erforderlich
cd /usr/local/ # Or wherever you installed Homebrew.
git checkout 2b7b4b3 Library/Formula/qemu.rb
- Dann installieren
gcc
, was ich verlassen habe, um seinen Lauf zu laufen.
brew install https://raw.github.com/Homebrew/homebrew-dupes/master/apple-gcc42.rb
- Dann installieren
pkg-config
brew install pkg-config
- Und schließlich (!) QEMU
brew install qemu --env=std --cc=gcc-4.2
Dann sind mir die Anweisungen dieser Seite leider fehlgeschlagen, da die Links zu zImage
und rootfs
Dateien auf der Dropbox aufgrund eines Überabonnements gelöscht wurden und ich eine andere Methode finden musste. Ich beschloss, darauf zu schlafen, da ich inzwischen irritiert war.
Am nächsten Morgen, nach einem nicht so erfrischenden Schlaf, fand ich den Link QEMU - Emulation Raspberry Pi auf einfache Weise (Linux oder Windows!) 1 , der es mir ziemlich ermöglichte, dort weiterzumachen, wo ich aufgehört hatte.
- Herunterladen der PI-Bilder von der Raspberry PI-Downloadseite
- Herunterladen des Linux-Kernels (was
brew install wget
vorher erforderlich war):
wget http://xecdesign.com/downloads/linux-qemu/kernel-qemu
- Überprüfen der verfügbaren Emulationsmodi von qemu:
qemu-system-arm -cpu ?
- Erster Start
qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw init=/bin/bash" -hda 2013-09-25-wheezy-raspbian.img
Dies führte zu einem Zyklus von SCSI-Fehlern.
ABBRUCH, GERÄTE-RESET, BUS-RESET, HOST-RESET, sym0: SCSI-BUS wurde zurückgesetzt, HOST-RESET, Gerät ausgeschaltet
und so weiter, durch ständig steigende SCSI-Geräte-IDs, n , ( scsi 0:0:*n*:0
). n = {0, 1, 2 ... 6, 8, 9 ... 15} 7 wurde übersprungen, da es sich vermutlich um den Host-Controller handelt.
Es würde bis zu SCSI ID = 14,
Wenn die Konsole im QEMU-Fenster bei SCSI ID = 15 schließlich abstürzt,
Lassen Sie den folgenden Fehler in dem Terminal, von dem aus es ausgeführt wurde.
snowserv:local user$ qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw init=/bin/bash" -hda ~/Documents/PI\:Arduino/Lapdock/Raspberry\ PI\ Disk\ Images/2015-02-16-raspbian-wheezy.img
Uncompressing Linux... done, booting the kernel.
pflash_write: Unimplemented flash cmd sequence (offset 00000000, wcycle 0x0 cmd 0x0 value 0xf000f0)
pflash_write: Unimplemented flash cmd sequence (offset 00000000, wcycle 0x0 cmd 0x0 value 0xf0)
snowserv:local user$
Ich habe versucht, den gleichen Befehl mit dem Präfix zu verwenden sudo
, aber das gleiche Problem ist aufgetreten.
Ich dachte, dass das Problem das war root=/dev/sda2
. Das lokale Kopieren des Raspbian-Images half nicht (es befand sich auf einer separaten Partition). Bei Betrachtung der Kommentare auf der Webseite erhielten einige Personen dieselben SCSI-Fehler.
Es schien ein Problem mit der Version von QEMU zu sein. Ich habe 1.1.50 verwendet
qemu-system-arm --version
Nach einigem Hin und Her fand ich die neuere Version 2.2.0
Ich habe ausgecheckt fce79940eb
git checkout fce79940eb Library/Formula/qemu.rb
Die ältere Version wurde nicht verlinkt
brew unlink qemu
Installieren Sie die neue ausgecheckte Version
brew install qemu --env=std --cc=gcc-4.2
Und den ersten Startbefehl ausführen
qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw init=/bin/bash" -hda 2013-09-25-wheezy-raspbian.img
Diese Zeit führte zur erwarteten Eingabeaufforderung.
Ich habe die vorgeschlagenen Änderungen von /etc/ld.so.preload
und /etc/udev/rules.d/90-qemu.rules
ohne Probleme durchlaufen .
Allerdings konnte ich nicht halt
, shutdown
oder reboot
der Pi. Die erhaltenen Fehler waren
init: /run/initctl: No such file or directory
Am Ende habe ich einen harten Neustart durchgeführt, indem ich einfach die QEMU-App beendet habe.
Im Terminal waren viele
coreaudio: Could not lock voice for audioDeviceIOProc
Reason: Invalid argument
Fehler protokolliert. Wahrscheinlich aufgrund fehlgeschlagener Pieptöne aufgrund fehlgeschlagener Abschaltungen.
Ich wiederholte den ersten Start, als Google 2 vorschlug, dass das init
Problem einfach durch einen Hardboot behoben werden könnte, aber ich hatte immer noch die Startfehler und die Stoppfehler.
Es gab jedoch eine "bessere" Möglichkeit zum Herunterfahren, da mir der Tipp (siehe unten) gegeben wurde
reboot -f
hat funktioniert.
Um die init
Fehler zu verlieren , habe ich nach einigem googeln 3 die folgenden Befehle ausgeführt:
mkfifo /dev/initctl
aber vorhersehbar war es nicht dauerhaft und reparierte das Herunterfahren nicht.
mkfifo /run/initctl
Das war hartnäckig, hat aber das Herunterfahren nicht behoben.
Ich bin auf henje bei Super User gestoßen , der das gleiche Problem hatte. Vom Herunterfahren: / run / initctl: Keine solche Datei oder kein solches Verzeichnis
Danke für die reboot -f
. Guter Tipp. Nach weiterem googeln soll ein harter Neustart das Problem beheben, hat es aber nicht. Ich habe auch ausgeführt,
mkfifo /run/initctl
was den
Fehler Keine solche Datei oder Verzeichnis stoppt , aber das System immer noch nicht herunterfährt. Ich verstehe jetzt init:
timeout opening/writing control channel /run/initctl
. Ich habe das /run/initctl
gerade erstellte mit dem auf meinem funktionierenden RPi verglichen und sie sehen identisch aus : prw------- 1 root root 0 Jan 1 1970
/run/initctl
.
Ich fuhr trotzdem fort und führte den richtigen Startbefehl aus , den gleichen wie beim ersten Start, abzüglich desinit=/bin/bash
qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -hda 2013-09-25-wheezy-raspbian.img
Es wurde anscheinend ohne Probleme auf dem raspi-config
Bildschirm gestartet . Ich habe den Hostnamen und pi
das Passwort des Benutzers geändert . Drücken Sie dann Fertig stellen und stimmen Sie dem Neustart zu. Die QEMU wurde gerade beendet und schien zu sterben. Das Fenster verschwand.
Ich habe den gleichen richtigen Boot-Befehl erneut ausgeführt
qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -hda 2013-09-25-wheezy-raspbian.img
Befehl erneut. Es wurde mit der normalen Textkonsolenanmeldung gestartet. Eingeloggt, ausgeführt startx
, X kann sich anmelden . Ran sudo shutdown-h now
. Systemstillstand ohne Missgeschick, System halted
Nachricht hinterlassen . Obwohl die CPU zu 100% laufen blieb und das Fenster nicht geschlossen wurde. Ich musste es manuell schließen.
Lief den gleichen richtigen Boot- Befehl erneut aus und startete OK. Es wird fsck
jeder Boot ausgeführt, daher bin ich mir nicht sicher, ob dies darauf hindeutet, dass das halt
nicht richtig funktioniert, oder ob Raspbian dies ohnehin bei jedem Boot tut. Daraufhin sudo halt
sehe ich jedoch die Nachricht
[ ok ] Unmounting local file systems...done.
Ich gehe also davon aus, dass es in Ordnung und normal ist.
Ich hoffe, dass diese (weitläufige) Geschichte jemand anderem hilft.
1 Es gibt viel zu viele Informationen, um sie im Falle eines Link-Todes zusammenzufassen.
2 Laut kann Debian und systemd-sysv nicht neu gestartet werden, sysvinit: Probleme beim Neustart beim Umschalten zwischen systemd-sysv und sysvinit
3 Laut habe ich ein Fehlerflag "init: / dev / initctl: keine solche Datei" erhalten