Edit 17.03.2014: * Anleitung zum korrekten Flashen des NAND-Speichers mit dem Stand, den man aktuell auf seiner µicroSD-Karte hat. Das ist ein Workaround/Fix, für das "/root/nand-install.sh" Skript aus slovenia's Debian Wheezy Server Image.
* Zusätzlich noch eine Anleitung hinzugefügt, um die LED-Anzeigen nach eigenem Belieben anzupassen.
* Schaltpläne und PCB-Layout für den Cubietruck hinzugefügt.
Hi all,
seit einigen Tagen bin ich stolzer Besitzer eines Cubietrucks und so begeistert davon, daß ich diesen Thread ins Leben rufen wollte. Er soll die wichtigsten Fragen zum Cubietruck klären und für Diskussionsstoff rund um diesen sorgen. Alle Cubietruck-Besitzer und Interessierten sind hierzu herzlich eingeladen.
Was ist der Cubietruck überhaupt?
Der Cubietruck ist -ähnlich dem weltbekannten RaspberryPi- ein Einplatinen-Computer. Um genauer zu sein ein ARM-Board (SoC). (Unterschiede der einzelnen SoC wird hier erklärt) Der richtige Name ist eigentlich Cubieboard3 und bezeichnet die dritte Version des Cubieboards, die auf dem Markt gebracht wurde. Der Spitzname des Cubieboard3 lautet eben CubieTruck. 'Truck' wahrscheinlich deswegen, weil es von all den vorherigen cubieboards (cubieboard1, cubieboard2) das Größte und Stärkste ist.
Das Cubietruck Board ist somit eine überarbeitete Version des Cubieboard 2 und basiert auf einer Allwinner A20 (Dual Core ARM Cortex-A7) CPU.
Highlights:
Das cubieboard3 bekam im Vergleich zu seinem Vorgänger (=cubieboard2) eine 1000MBit/s-Netzwerkschnittstelle, onboard WiFi + Bluetooth, RTC Echtzeituhr-Batterie, 2GB RAM, einen VGA-Anschluss und die Möglichkeit als Stromversorgung Batterien zu verwenden. Das Besondere am Cubietruck ist, dass er auch eine SATA 2.0 Schnittstelle und somit die Anschlussmöglichkeit einer 2.5" oder 3.5" Festplatte bietet. Eine 2.5" Festplatte kann somit problemlos über das board betrieben werden (ohne extra Stromversorgung) und sie kann auch ins Gehäuse mit eingebaut werden. Das funktioniert auch mit dem original beigefügtem Acryl-Gehäuse (siehe drittes Bild), aber auch mit dem schicken Ewell-Gehäuse, das weiter unten erklärt und gezeigt wird.
Ausstattungsmerkmale:
- AllWinnerTech SOC A20,ARM Cortex-A7 Dual-Core ARM Mali400 MP2 Complies with OpenGL ES 2.0/1.1
- 2 GB DDR3 SDRAM mit 480 MHz
- 8 GB NAND-Flash, vorinstalliert mit Android 4.2.2
- HDMI- und VGA-Ausgang 1080p mit ESD protectors
- 1x MicroSD Steckplatz
- 1x SATA 2.0 Anschluss mit Unterstützung für 2.5" HDD (für 3.5" HDD wird der 12V-Adapter benötigt, Preis 10,- EUR). Es werden auch SSDs unterstützt.
- 2x USB 2.0 Schnittstellen
- 1x miniUSB 2.0 OTG-fähige Schnittstelle
- 10/100/1000 MBit/s RTL8211E Ethernet PHY Netzwerkinterface
- S/PDIF audio interface, Kopfhörer- und HDMI-Audio-Ausgang, Mikrophone und Line-Eingang via externer Anschlusspins
- WLAN und Bluetooth (BCM AP6210) onboard via PCB-Antenne (Chip: Broadcom BCM4329/BCM40181), RTL8211E 10M/100M/1G Ethernet PHY
- Built-in IR receiver
- RTC Echtzeituhr-Batterie. Das heißt selbst wenn keine Stromversorung da ist, läuft die Uhr brav weiter und wird nicht verstellt.
- 54 Anschlusspins einschließlich I2S, I2C, SPI, CVBS, LRADC x2,UART, PS2, PWMx2, TS/CSI, IRDA, LINEIN&FMIN&MICIN, TVINx4 with 2.0 pitch connectors, keine LVDS mehr
- Abmessungen: 11 cm × 8 cm x 1,4mm
- Das Board hat 3 buttons angebracht und zwar "PWR-ON", "RESET" und "FEL". Die ersten zwei sind selbsterklärend. "FEL" ist ein besonderer Recoverymodus. Man kann z.B. über den USB OTG Port anhand dieser Anleitung booten.
- Stromversorgung entweder mit DC5V @ 2.5A (empfohlen für 2.5" HDD Betrieb), aber auch Unterstützung von 3.6/3.7V-Li-Ion-Akkus.. Es sollte auch mit 500mA arbeiten, bloss wenn man eine Festplatte betreibt, sollte man mindestens 2A Strom liefern können damit die Festplatte richtig arbeitet. Man kann den Cubietruck somit auch mit einem USB-Kabel ans Laptop oder sonstigem USB-Host anschließen und betreiben. Er kann dann natürlich wegen der USB-Spezifikation nur 500mA ziehen (z.B. vom Laptop oder sonstigem Computer) und deshalb wäre so ein Betrieb mit einer zusätzlichen HDD nicht möglich. Also: wenn ihr eine HDD mit dem Cubietruck betreiben wollt, dann am besten das weiter unten in der Artikelliste verlinkte 2,5A Netzteil nehmen, kostet ja auch nur 8,- EUR.
Hinweis: GPIO-Abstand der Pins beträgt leider nicht die üblichen 2.54mm, sondern nur 2.0mm
A20 SoC Features
- CPU
- ARM Cortex-A7 Dual-Core 1GHz
- 256KiB L2-Cache (shared between two cores)
- 32KiB (Instruction) / 32KiB (Data) L1-Cache per core
- SIMD NEON, VFP4
- Virtualization
- Large Physical Address Extensions (LPAE) 1TB - GPU
- ARM Mali400 MP2
- Featuring 1 vertex shader (GP) and 2 fragment shaders (PP).
- Complies with OpenGL ES 2.0 - Memory
- LPDDR2/DDR3/DDR3L controller
- NAND Flash controller and 64-bit ECC - Video
- HD H.264 2160P video decoding
- Full HD video decoding
- BD Directory, BD ISO and BD m2ts video decoding
- H.264 High Profile 1080P@30fps encoding
- 3840×1080@30fps 3D decoding
- Complies with RTSP, HTTP,HLS,RTMP,MMS streaming media protocol - Display
- Support multi-channel HD display
- Integrated HDMI 1.4
- CPU/RGB/LVDS LCD interface 1920×1080 resolution
- CVBS/YPbPr/VGA support
- Integrated TV decoder - Camera
- Integrated parallel 8-bit I/F YUV sensor
- Integrated 24-bit parallel YUV 444 I/F
- 5M/8M CMOS sensor support
- Dual-sensor support - Audio
- Integrated HI-FI 100dB Audio Codec
- Dual MIC noise cancellation
Es gibt ja 'nen Haufen ARM-Boards mittlerweile auf dem Markt und die spriesen regelrecht aus dem Boden. C't hat neulich einige davon behandelt. Es kommt -wie auch im Artikel erklärt- immer darauf an, was man eigentlich damit machen möchte. In meinem Fall, war ich auf der Suche nach einer stärkeren Alternative für meinen RaspberryPi. Mit meinem RaspberryPi betreibe ich einen 128GB USB Stick als Datenspeicher und eine 16GB MMC-Karte für das OS.
Hier die Punkte, die mich dazu bewegten nach einer RaspberryPi Alternative zu suchen:
- USB-Stick ist ein Flash-Speicher und nicht gerade empfehlenswert für Datenarchivierung über längeren Zeitraum. Vor allem durch den Flash hat er eben eine begrenzte Lebensdauer. Ich hatte schonmal den Fall gehabt, dass ein solcher USB-Stick von jetzt auf nachher seinen Dienst quittierte und Kernel panic verursachte. Er war danach nicht mehr formatierbar, unter keinem OS. Das ist für Datenspeicherung natürlich alles andere als was man sich wünscht. Daher USB als Datengrab nichte empfehlenswert. Das weiß ich ja und will deshalb weg von USB-Stick.
- eine externe Festplatte will ich nicht, erst recht keine die mit extra Strom versorgt werden muss. Im Vordergrund meines mini-Rechners steht die Kompaktheit, Einfachheit und Flexibilität. Ich könnte mir ja auch einen HP Microserver N54L zulegen und hätte genug Power und Anschlussmöglichkeiten, das ist aber für meine Anforderungen trotzdem ein ganz andres Kaliber. Außerdem auch viel teurer. Einzige Alternative wäre eine 2.5" HDD, mit der ich mich anfreunden könnte, sowohl von Größe als auch vom Gewicht. Eine 3.5" wiederum wäre mir zu oversized für ein kleines ARM-board. Daher suchte ich nach Boards mit SATA-Anschlussmöglichkeit.
- Kostenpunkt: pro mini-PC möchte ich komplett max. ~ 200 EUR ausgeben, das heißt ein Komplettsystem (ohne Monitor+Tastatur+extra Peripherie) da ich mir insgesamt zwei oder drei Stück davon aufbauen möchte. Aus dem Grund (und aus Energieverbrauchsgründen) käme ein NUC oder HP Microserver nicht in Frage. Auch der Zotac-Barebone ZBOX ID18 scheidet aus, da hierzu noch RAM und Festplatte hinzugerechnet werden müßten. Außerdem weiß ich nicht, ob der Zotac mit Debian Wheezy betrieben werden könnte, da habe ich gar nicht erst weiter recherchiert.
- extremer Schwachpunkt beim RPi für meinen Einsatzzweck ist: USB und NIC hängen am selben Bus und teilen sich die Bandbreite. Außerdem hat der Rpi nur eine 100MBit/s NIC, die für meinen Zweck leider unzureichend ist. Das macht sich deutlich bemerkbar, wenn ich Dateien auf/zu vom RaspberryPi kopiere (Samba). Die Übertragungsrate einer Fastethernet NIC läßt sehr zu wünschen übrig, und andrerseits ist der limitierende Faktor dann wiederum der USB-Stick. Da die beide schlechten Faktoren sogar am selben Bus hängen, kommen dadurch Übertragungsgeschwindigkeiten von ca. 3 MB/sec heraus, das ist ätzend. Netio, bzw. iperf zeigen zwar 11MB/sec (=entspricht knapp 90MBit/s) aber zusammen mit USB-Stickbetrieb geht das alles enorm in die Knie. Man kann z.B. auf der Samba-Freigabe auch sehr mühsam mit einem Windows-Rechner einen Bildordner betrachten. Das Laden der Thumbnails dauert schon, und man muss schon einige Sekunden waren bis jede Ansichtsseite mit all den Thumbnails geladen werden (klar, ist zwar nur einmalig, und wird in der cache.db anschließend gespeichert, aber wenn man mal einen noch nicht-indizierten Ordner betrachtet und ein bestimmtes Bild sucht, ist das sehr nervig)
Meine Anforderungen waren deshalb:
- Servereinsatz im 24/7 Dauerbetrieb, lüfterlos
- möglichst geringe Energieverbrauchswerte, daher stromkostengünstig
- als NAS/fileserver nutzbar, mit mindestens 200GB Kapazität, daher Suche nach SATA-Möglichkeit, und zwar so, dass ich ohne extra Stromversorgung eine 2.5" Festplatte betreiben könnte durch das eigene Board
- Gigabit-NIC, damit das Kopieren von größeren Datenmengen vom/zum System nicht zur Geduldsprobe wird
- max. 200 EUR mit allem drum und dran
- möglichst klein und handlich, daher flexibel transportierbar
Nachdem ich mehrere Tage und Nächte recherchiert habe, entschied ich mich ganz klar für den Cubietruck. Es gab da Alternativen, wie z.B. das Wandboard Quad oder die ODroid-Modelle. Jedoch habe ich herausgelese, dass da die OS-Unterstützung für Debian nicht so einfach wäre, bzw. gabs Sachen wie "die NIC liefert nicht ausreichend Performance, aufgrund eines silizium-bugs, und die Gigabit-NIC im Wandboard liefere nur 300-400 MBit/s in der Praxis). Klar, beim Cubietruck weiß ich, dass die Gigabit-NIC auch nur 500-550 MBit/s packt, aber das ist immerhin ganz gut wenn ich mit dem RaspberryPi vergleiche. Wie auch immer, ich entschied mich für den Cubietruck, weil es dafür auch schon mittlerweile fertige Debian-Images gibt.
Was hat mich das alles gekostet? Meine Zusammenstellung:
Aufstellung der einzelnen Komponenten (Beispiel: mein eigener Cubietruck)
Cubieboard3 (=Cubietruck:) 89,- EUR
Ewell Gehäuse mit 2.5" Einbauschacht für 'ne Festplatte (12,- EUR)
Passendes Netzteil mit 2,5A, das 100%ig funktioniert und ausreichend ist um eine SATA-Festplatte 2.5" zu betreiben (9,- EUR)
Eine 8GB microSDHC Karte mit ~30MB/sec für 8,- EUR oder eine 16GB microSDHC Karte Sandisk mit ~45MB/sec für 25,- EUR
Lieferumfang:
- Cubietruck main board x1
- SATA 2.0 cable x1
- Mini USB to OTG x1
- Mini USB cable x1
- USB to 1.7 mm DC jack cable x1
- Acrylic shell x1
- Ultrathin Heat Sink x1
Es bringt nix, wenn man eine teurere/bessere/schnellere microSDHC Karte kauft, denn der Cubietruck schafft aufgrund des Buses nur max. ~25MB/sec. Das haben diverse User durch Benchmark-Tests miteinander verglichen und ausdiskutiert. Deswegen lohnt sich eine schnellere Karte nicht unbedingt. Ich für meinen Teil hab die 16GB microSDHC Karte in Nutzung, und bin momentan mehr als zufrieden. Wenn man aber mit weniger Speicherplatz auskommt für sein OS, so kann man problemlos auch eine kleinere µicroSD Karte nutzen. Mann kann auch gänzlich auf eine µicroSD Karte verzichten: Dazu kopiert man den Bootloader auf den onboard NAND-Flash und lagert seine Root-Partition auf eine angeschlossene Festplatte aus. Dieses Szenario wird hier und hier erläutert.
Hinweis: Wer für den Cubietruck das Debian Wheezy Server image vom user "slovenia" verwenden möchte (siehe weiter unten im Abschnitt "Debian OS auf dem Cubietruck"), der sollte sich die Anleitung in diesem weiter unten genannten Abschnitt durchlesen. Dort wird genau beschrieben, wie man ganz easy ohne großem drumrum den Inhalt der µicroSD-Karte ganz easy auf den NAND-Speicher übertragen kann.
Als Datenplatte kann man sich irgendeine 2.5" Festplatte raussuchen. Ich hab mir eine WesternDigital Red mit 1TB Speicherplatz für 67,- EUR gegönnt, da ich die WD Red Platten schon länger in verschiedenem Umfeld betreibe und sehr zufrieden bin. 1TB war für mich völlig ausreichend.
Alles in allem hat mich das also 200,- EUR gekostet und damit hab ich ein TOP-System in schickem Gehäuse mit 1TB Speicherplatz und damit kann man echt viel anstellen. Hier findet man auch eine Anleitung, wie das verbaut wird und wie es dann aussieht mit diesem Ewell Gehäuse. Man hat mit Ewell Case ein echt schickes und durchdachtes Gehäuse.
Der Cubietruck hat 'ne DualCore CPU mit 1GHz und 2GB RAM. Außerdem hat es onboard WiFi, eine Gigabit-NIC (mit der du jedoch nur die Hälfte an Leistung rauskitzeln kannst, also max. 550MBit/s, das aber trotzdem noch 5x schneller wie eine normale FastEthernet 100MBit/s NIC ist!), Audio IN/OUT, SPDIF optischer Ausgang, HDMI, VGA, und vieles vieles mehr...
Community:
Wie ich schon bereits erklärte, das Cubieboard hat eine ganz gute community, die stets weiter anwächst. Der RaspberryPi hat natürlich die weltweit größte community, und das ist (noch) nicht zu toppen. Aber beim cubieboard hab ich den Eindruck gehabt, dass es doch weltweit angesehen ist und dass sich sehr viele für dieses Board interessieren und auch Unterstützung geben. Das war beim Wandboard oder dem ODroid leider nicht der Fall (zumindest kam mir das so vor). Das war auch einer der Hauptgründe, warum ich mich für das Cubieboard3 entschieden habe, da man doch recht hilfreiche Infos, Tools, und Software dazu findet.
Debian OS auf dem Cubietruck:
Der User "slovenia" (=Igor Pecovnik) aus dem Forum http://www.cubieforums.com bietet ein Wheezy-Image an, welches man problemlos und sehr easy (wie beim Raspberry Pi auch) auf seine microSD Karte flashen kann und so gleich mit Debian Wheezy loslegen kann. Das Projekt wird in github gepflegt, und man sieht an dem Skript wie es hergestellt wurde. Da ich selbst erst seit wenigen Tagen ein Cubietruck-User bin, hatte ich auch "Cubian" ausprobiert. Mir wurde anfangs nämlich der Anschein erweckt, daß es sich bei Cubian um die offizielle Debian-Version für das Cubieboard3 handle. (Also so wie z.B. das Raspbian beim Rasp berryPi). Damit lag ich jedoch falsch, denn Cubian ist NICHT offiziell mit Cubieboard in Verbindung zu bringen ! Allerdings schmeckt mir die ganze Cubian-Geschichte nicht, da es wenig Infos zu dem Author gibt, die Seite cubian.org über anonyme Proxys gehostet wird, und man keine Einsicht hat wie das Image erstellt wurde und was es so beinhaltet.
Mittlerweile verwende ich "slovenia's" Image und muss sagen, dass es mir bisher sehr gut gefällt. Der Cubietruck bootet sowas von pervers schnell, dass ich meinen Augen nicht traute. Es hat die meisten Optimierungen und Tweaks schon eingebaut und bisher kann ich micht wirklich nicht beklagen.
Wer sich Debian von Hand selbst installieren möchte, der liest sich am besten hier, hier und hier durch.
Anleitung um den Inhalt einer mit einem Debian-Image ausgestatteten µicroSD-Karte in den onboard NAND-Flashspeicher zu kopieren:
Das Image von "slovenia" stellt ein Skript bereit, unter "/root/nand-install.sh". Dieses Skript überträgt normalerweise den Inhalt der aktuell verwendeten µicroSD-Karte in den NAND-Flashspeicher. Wer das jedoch probiert, wird feststellen, dass anschließend nicht mehr vom NAND-Speicher gebootet werden kann, der NAND-Flash verhält sich so als ob er korrupt wäre. Man kann nicht von ihm booten. Stattdessen muss zwangsweise wieder von einer gültigen µicroSD-Karte gebootet werden. Das liegt daran, daß einige versteckte Dateien in ein verstecktem NAND-Speicherbereich vor der ersten /dev/nand? Partition platziert werden müssen. Das in den meisten Images vorhandene "nand-install.sh" Skript beinhaltet jedoch diese zwei boot0/boo1 Dateie nicht und es wird auch ein benötigtes Magic Byte nicht in den Bootloader/NAND geschrieben. (siehe auch HIER) Deshalb kann anschließend vom NAND-Flash nicht gebootet werden.
Abhilfe schafft man durch folgende Anleitung (ich erklärs mit der Software PhoenixSuite für Windows, da ich grad an einem Windoof-Laptop sitze):
- wir entfernen die µicroSD-Karte aus dem Cubietruck, auf welcher sich das Debian Wheezy Server image vom user "slovenia" befindet.
- Man lade sich erstmal ein fertiges Lubuntu image herunter, dass diese benötigten Boot-Komponenten beinhaltet. z.B. das Lubuntu server image für den CT v1.02. Die downgeloadete Datei "lubuntu-desktop-nand-hdmi.img.gz" entpacken wir in ein Verzeichnis unsrer Wahl.
- Das Softwaretool "Phoenix Suit v1.0.6" downloaden und installieren. Die Warnmeldungen für die Treiberkomponenten habe ich einfach mal bejaht, damit das Tool funktionieren kann.
- Wir starten PhoenixSuit und klicken auf den zweiten Reiter mit dem Ankersymbol und dem Text "Firmware". Wir wählen das im Schritt zuvor entpackte Image namens "lubuntu-server-nand.img" aus und bestätigen.
- Jetzt nehmen wir unseren Cubietruck und das mit dem Cubietruck mitgelieferte USB-Kabel, das einem Ende einen miniUSB-Anschluss aufweist und legen es neben das Notebook. Noch nicht verbinden! Wir werden den Cubietruck gleich mit diesem Kabel über dessen USB-OTG Schnittstelle und der USB-Schnittstelle am Notebook verbinden, siehe folgender Schritt...
- Wir halten die FEL-Taste am Cubietruck (befindet sich seitlich, neben dem reset-button) gedrückt, und verbinden während wir FEL gedrückt halten den Cubietruck mit dem Notebook. FEL-button so lange gedrückt halten, bis Windows den Debug-Modus des Cubietrucks erkannt hat und seine Treiber installiert. Das kann eine Weile dauern weil auch windows-Update womöglich durchsucht wird.
- Es wird ein Fenster aufpoppen, indem wir gefragt werden ob wir mit JA oder NEIN antworten. Bitte mit JA antworten, damit der Flash vollständig beschrieben wird. Der FLASH-Speicher wird daraufhin komplett platt gemacht und mit den benötigten Dateien geflasht.
- Wenn der Debugmodus des Cubietrucks vollständig von windows erkannt wurde, startet automatisch der Flashvorgang. Der laufende Zustand und verbleibende Zeit wird uns dabei angezeigt.
- Wenn der Flashvorgang beendet wurde, kann man den Cubietruck wieder vom Computer trennen. Nun sollte ohne eingelegter µicroSD-Karte der Cubietruck booten und zwar wird Lubuntu Server gebootet und landet wegen der automatischen Loginfunktion von alleine irgendwann in einem root-prompt. Wenn das geklappt hat, ist der NAND-Flash also ordnungsgemäß beschrieben und bootfähig.
- wir fahren den Cubietruck mit z.B. "shutdown -h now" wieder herunter und stecken anschließend unsere µicroSD-Karte mit slovenia's Debian Wheezy Image wieder ein.
- Cubietruck einschalten, damit von der µicroSD-Karte gebootet wird. Nun rufen wir das "/root/nand-install.sh" Skript auf. Die Frage mit JA beantworten und ein wenig warten. Das Installationsskript wird sich wieder melden und sagen, dass der Cubietruck rebootet werden muss, und dass man erneut dieses nand-install.sh Skript aufrufen sollte. Das tun wir dann auch.
Hinweis: solltet ihr während dem Installationsskript irgendwelche Meldungen sehen, dass eine Datei namens "nand1-cubietruck-debian-boot.tgz" nicht gefunden und verarbeitet werden konnte, so ladet euch diese Datei einfach in das /root Verzeichnis herunter mit dem Befehl "wget https://www.dropbox.com/s/7puy5v0v3pk7y ... n-boot.tgz". Ihr müßt die nand-install.sh daraufhin wieder neu starten. - Nachdem der Cubietruck also automatisch durch das nand-install.sh gebootet wurde, starten wir wieder das Skript "/root/nand-install.sh" und warten einige Minuten bis es vollständig durchgelaufen ist und sich ohne Fehler beendet.
- Der Installationsvorgang wird daraufhin automatisch den Cubietruck herunterfahren.
==> Fertig, das war's! Wenn ihr nun die µicroSD-Karte wieder aus dem Cubietruck entfernt, sollte der Cubietruck von seinem onboard NAND-Flashspeicher booten, und zwar euer bisheriges image, dass auch auf eurer µicroSD-Karte drauf war.
The simple solution is to install a valid lubuntu to nand via phoenix/livesuit. Check if it is bootable. That provides the boot files to nand. Then execute the copy to nand script from your sdcard distro."[/quote]
Anleitung, um die LEDs zu steuern und nach eigenem Belieben zu konfigurieren:
Der Cubietruck besitzt 4 LEDs (blau, orange, weiß, grün). Wer das Image vom user "slovenia" nutzt, wird feststellen, daß die LEDs ohne Funktion sind. Der hat nämlich in seinem Image defaultmäßig eingestellt, dass alle LEDs deaktiviert werden nach systemboot, weil er das LED-Geflackere nicht haben wollte. Das wird durch ein init.d Skript erzielt, welches unter "/etc/init.d/disable_led.sh" gesteuert wird. Dieses Skript wird automatisch bei jedem Systemboot aufgerufen (runlevel 2). Wer also möchte, dass seine LEDs wieder flackern, der könnte einfach den Befehl "update-rc.d disable_led.sh remove" auf seiner prompt ausführen. Damit wird dieses Skript nicht automatisch bei einem Systemboot ausgeführt, und demnach die LEDs nicht forciert ausgeschalten. Sie leuchten/blinken also wieder froh fröhlich. Nun zu der Statuserklärung: die blaue LED ist mit der Triggerfunktion "Heartbeat" eingestellt, die orangene LED zeigt den Status der cpu0 an, die weiße LED den Status der cpu1, und die grüne LED den Status der mmc0-Aktivität (also Schreib-/Lesevorgang des Speichers). Hier ist eine Erklärung zu der LED-Konfiguration auf linux-sunxi.org. Wer sich das näher anschauen möchte, der kann mit dem Befehl "bin2fex /boot/ct-hdmi.bin >/boot/ct-hdmi.fex" seine aktuell genutzte Datei (in meinem Falle ist es der Loader für Cubietruck-HDMI) umwandeln, und dann in der eben erstellten datei "/boot/ct-hdmi.fex" die gewünschten Anpassungen durchführen (einfach nach 'led' suchen, damit man den jeweiligen Abschnitt schnell findet). Danach abspeichern und mit dem Befehl "cp /boot/ct-hdmi.bin /boot/cd-hdmi.bin.bak && fex2bin /boot/ct-hdmi.fex >/boot/ct-hdmi.bin" kann man wieder die .bin Datei erstellen ,die beim Booten dann vom Cubietruck genutzt wird. Der Befehl erstellt außerdem sicherheitshalber noch eine Kopie bevor die .bin neu geschrieben wird. Wer z.B. die Funktion der blauen oder grünen LED ändern möchte, der kann auch andere Trigger zuweisen. Eine Liste der möglichen Trigger kann man sich anzeigen lassen mit dem Befehl "cat /sys/class/leds/blue\:ph21\:led1/trigger". Ich habe mir z.B. die Funktion "disk-activity" für die blaue LED zugewiesen, denn damit signalisiert mir die blaue LED Festplattenaktivität meiner angeschlossenen 2.5" Festplatte. Das kann man entweder einmalig durch den Befehl "echo disk-activity > /sys/class/leds/blue:ph21:led1/trigger" erzielen und anschließend mit "cat /sys/class/leds/blue:ph21:led1/trigger" überprüfen. Die aktuell gewählte Trigger-Einstellung wird in eckigen Klammern hervorgehoben. Diese Methode ist aber nur solange gültig, bis wieder gebootet wird, dann ist die Einstellung hinüber. Wenn man das permanent in die Bootdatei abspeichern möchte, muss man die zuvor umgewandelte /boot/ct-hdmi.fex bearbeiten und in der jeweiligen Zeile (in meinem Falle Zeile 283) reinschreiben, abspeichern und zurück in .bin Datei konvertieren. Ferdisch
Zum Lesen, für Fragen oder Download, hier ein paar Links:
http://docs.cubieboard.org
http://linux-sunxi.org/Cubieboard/FAQ
http://docs.cubieboard.org/faq/faqs
http://www.cubieforums.com/index.php?PH ... wwRedirect
http://www.forum-cubieboard.de
http://linux-sunxi.org/Optimizing_system_performance
http://linux-sunxi.org/Kernel_arguments
http://stefanius.de/tutorial-sd-card-image-schrumpfen
http://dl.cubieboard.org/hardware/A20_C ... 130606.pdf