ROCK64 - Pine64

C1500

Servus,

ich hab jetzt den Rock64 mit der eMMC lauffähig.

Hab einfach SD raus und alles auf eMMC installiert.

ABER:

Der ETH läuft so gut wie nie.

Ich hab mir jetzt damit geholfen, das ich wieder den USB-ETH Adapter verwende.

Sobald ich über den USB-ETH mal eine Verbindung habe, funktioniert auch die Onboard, leider aber auch nur bis zum nächsten Reboot.

Es muss also noch irgend ein Fehler in der ETH Config vom Rock64 sein.

Eine Reaktivierung von SSH bringt leider auch nichts.

Jetzt noch ganz kurz zu meinem Hauptanliegen.

Wie bekomme ich das System vom Pi auf den Rock64 ohne alles einzeln neu installieren zu müssen?

Gibt es da einen Trick?

Oder ganz naiv gefragt: ;o)

Sind die ganzen Adapter und Skripte alle unter /opt/iobroker ?

Bringt das was per WinSCP das Verzeichnis komplett zu kopieren?

Vermutlich aber eher nicht da mit Sicherheit in vielen anderen Verzeichnissen noch Daten hinterlegt sind.

Klappt sowas vielleicht mit dem backitup Adapter?

Gruß Peer

Homoran

~~@C1500:~~

Es muss also noch irgend ein Fehler in der ETH Config vom Rock64 sein. `
da das bei mir absolut problemlos läuft liegt das Problem ggf. bei dir im Netz.

~~@C1500:~~

Wie bekomme ich das System vom Pi auf den Rock64 ohne alles einzeln neu installieren zu müssen?

Gibt es da einen Trick? `

cd /opt/iobroker
sudo iobroker backup

Datei aus /opt/iobroker/backups sichern, auf dem Rock dieses Verzeichnis anlegen und die Datei da hinein.

Anschließend

cd /opt/iobroker
sudo iobroker restore 0

~~@C1500:~~

Bringt das was per WinSCP das Verzeichnis komplett zu kopieren? `
Im Gegenteil, da die Hardware (und ggf. die node.js-Version) unterschiedlich sind, und die Pakete spezifisch kompiliert wurden.

~~@C1500:~~

Klappt sowas vielleicht mit dem backitup Adapter? `
oder so!

Gruß

Rainer

C1500

~~@Homoran:~~

~~@C1500:~~

Es muss also noch irgend ein Fehler in der ETH Config vom Rock64 sein. da das bei mir absolut problemlos läuft liegt das Problem ggf. bei dir im Netz.
Ich verwende das gleiche Kabel an beiden ETH´s, hab aber auch schon ein anderes Kabel ausprobiert.

Heute Nachmittag teste ich noch einen anderen Switch.

Aktuell hängt er zu Testzwecken eh nur an einer Powerline 540e und wandert irgendwann in Schaltschrank.

Komisch nur, das er an dem USB-ETH absolut problemlos funktioniert.

Könntest du mir bitte mal die Ausgabe von infconfig zusenden?

Würde das gern mal vergleichen

Das mit dem Backup probiere ich auch nachher direkt ;o)

Danke schon mal für die Hilfe

Gruß Peer

Homoran

~~@C1500:~~

Aktuell hängt er zu Testzwecken eh nur an einer Powerline 540e `
Aufhorch!

~~@C1500:~~

Komisch nur, das er an dem USB-ETH absolut problemlos funktioniert. `
dann kann es an der MAC-Adresse des onboard NIC liegen, dass dein Router damit ein Problem hat.

Oder der ARP-Cache inm Switch, oder, oder oder…

Gruß

rainer

C1500

Servus Rainer,

Mir ist da eh schon ein Unterschied zwischen den beiden ETHs aufgefallen wenn ich diese mit ifconfig anschaue.

Ich dachte erst an eine IP.V6 Einstellung am Onboard-ETH. Kann aber die eingestellt IP-V4 des Onboard-ETH IMMER problemlos anpingen.

Eine Idee war auch noch das die Paketgröße anders ist.

Ich poste nachher mal die beiden ifconfig ausgaben.

Vielleicht hilft das weiter.

@ foxriver76: Du hast ja ein ähnliches Problem mit dem ETH.

Woran hast du denn den Rock64 hängen?

Gruß Peer

EDIT um 17:04

Der Rock64 hängt jetzt direkt an der FritzBox. Leider auch hier keine SSH Möglichkeit

Ich hab aber vorher noch ifconfig am PowerLine gemacht, das sah dann so aus:

root@rock64:~# ifconfig
enx801f02xxxxxx: flags=4163 <up,broadcast,running,multicast>mtu 1500
        inet 192.168.23.58  netmask 255.255.0.0  broadcast 192.168.255.255
        inet6 fe80::3347:7d32:xxxx:xxxx  prefixlen 64  scopeid 0x20
        inet6 2003:c3:cf32:bd00:199a:6003:xxxx:xxxx  prefixlen 64  scopeid 0x0 <global>ether 80:1f:02:xx:xx:xx  txqueuelen 1000  (Ethernet)
        RX packets 154  bytes 14399 (14.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 139  bytes 20810 (20.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4099 <up,broadcast,multicast>mtu 1500
        ether 12:67:c2:d1:xx:xx  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 6  bytes 508 (508.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 40

lo: flags=73 <up,loopback,running>mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10 <host>loop  txqueuelen 1  (Lokale Schleife)
        RX packets 546  bytes 46715 (45.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 546  bytes 46715 (45.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root@rock64:~#</host></up,loopback,running></up,broadcast,multicast></global></up,broadcast,running,multicast>

Hilft dir das weiter bzw. hast du eine Idee?

foxriver76

Die älteren Rocks haben einen anderen Ethernetchip — Nummer auf dem Chip endet auf F die älteren auf E.

Bei mir hängt er an einem Devolo DLAN Adapter.

Homoran

Das kann irgendwie nicht sein.

Ich habe einen der allerersten

Gruß Rainer

foxriver76

~~@Homoran:~~

Das kann irgendwie nicht sein.

Ich habe einen der allerersten

IMG_20180917_192112.jpg

Gruß Rainer `

Okay, dann stimmt das wohl nicht. So hatte ich das zumindest einer Aussage im Armbian Forum nach interpretiert. Wenn ich das gerade nochmal lese, könnte man es auch anders interpretieren. ;)

C1500

Der ist bei mir auch drauf.

Ich hab aber einen blauen Punkt und Rainer einen orangenen Punkt auf der ETH Buchse :shock: :shock:

:lol: :lol: :lol:

C1500

Morgäähhhn

Kurze Zwischenfrage

Wie kann ich verhindern, das der Rock64 von eMMC bootet um diese zu leeren bzw zu formatieren?

Hab mir ioBroker gestern bei Backup versuchen noch komplett zerschossen und möchte daher das System wieder von ganz neuem aufsetzen.

Leider bootet er immer von eMMC auch wenn eine SD drin ist.

Könnte daran liegen das ich per Armbian-config auf MMC umgestellt habe. Da gibt es jetzt aber keine Auswahl um wieder von SD zu booten.

Oder finde ich es nur nicht?

Hab noch folgendes gefunden:

Hit any key to stop autoboot
write "mmc erase 0 1000"
then "boot"
it will erase the first 1000 block on your eMMC so the rock64 will not be able to boot on it and will boot on SD

Ich sehe nur leider nie einen Uboot um ihn anzuhalten sondern erst die die Anmeldung unter Linux

Vermutlich geht das dann so nur über die Debug RS232 und die müsste auf dem PI-Stecker sein.

Leider hab ich keinen USB-eMMC-Adapter sonst wäre es einfach.

Gruß Peer

EDIT:

hab gerade im Schalplan vom Rock64 den "SW2202 ON/OFF_key" entdeckt.

Der scheint ja den eMMC-CLK auf masse zu ziehen.

Dadurch kann man zumindest verhindern, das er von eMMC bootet.

Sobald er von SD gebootet hat, kann die eMMC ja wieder ihren CLK bekommen.

So werde ich das mal als erstes probieren.

Homoran

Jawohl,

Um bie montiertem eMMC von der sd zu booten muss der Jumper gesetzt sein.

Steht auch irgendwo ganz vorne.

Spassig wird es wenn du beides haben willst.

Gruß Rainer

C1500

Servus Rainer

ich hab jetzt das System sauber auf der SD-Karte und wollt es nun auf die eMMC per "sudo nand-sata-install" übertragen

Dazu hab ich S2202 kurzgeschlosse und somit von SD gebootet und nach dem booten den Jumper wieder raus genommen.

Jetzt taucht die eMMC Version aber nicht bei der Auswahl im nand-sata-install auf.

Schaut nur so aus:

Und nun?

Wie kann ich die eMMC nachträglich wieder erkennen damit ich die Daten übertragen kann?

Mein Netzwerk Problem scheint sich übrigens geklärt zu haben.

Ich kann mir es zwar nicht erklären, aber die FritzBox hat die IP 2x im DHCP vergeben

Sobald der andere Pi aus war, hatte ich keine Netzwerkprobleme mehr.

Hab jetzt dem Rock64 eine andere fixe IP vergeben und aktuell keine Probleme mehr

Gruß Peer

Homoran

Du musst innerhalb etwa 5 sekunden nach der stromzufuhr den jumper ziehen.

Ich schrob
~~@Homoran:~~

Spassig wird es wenn du beides haben willst. `

Gruß Rainer

C1500

Das mit den 5 Sekunden hatte ich übersehen, sorry.

Jetzt wird gerade auf eMMC übertragen. (UPDATE: Es hat funktioniert) :D

Hab allerdings die beiden nächste Probleme.

Kein USB Komponente läuft.

Der BT Stick wird erst gar nicht in dev angelegt.

Der JeeLink läuft auch nicht. Hier bin ich aber zumindest etwas weiter.

Auch wenn ich "cat /dev/ttyUSB" mache kommt nichts, obwohl die LED´s auf dem Stick anzeigen das da was gesendet wird.

Per stty -F /dev/ttyUSB0 57600 hab zwar die Datenrate richtig eingestellt bekommen und er zeigt dann per cat die Daten, Aber trotzdem wird der Stick immer wieder neu gestartet.

Dies erkennt man das er immer wieder seine Initialisierung sendet. (Screenshot kommt heute Abend)

Ganz selten schafft es dann mal eine Nachricht der Sensoren durchzukommen.

stty -F /dev/ttyUSB0 -a liefert folgendes:

root@rock64:~# stty -F /dev/ttyUSB0 -a
speed 57600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke -flusho -extproc</undef></undef></undef>

Hat hier noch jemand nen Tip?

Daran liegt auch vermutlich die Fehlermeldung die ioBroker gerade immer im LOG schreibt:

Gruß Peer

bimmi

Da ist er nun das gute Stück :)

Bis auf warn und deprecated Meldungen bei den Adapter installationen läuft eigentlich alles :) er ist schnell. Sehr schnell :) Das macht richtig Spaß!

Lieferzeit 10 Tage.

Wird eurer auch so heiß?

C1500

Jap, meist jenseits der 60°C

Werde mal einen Kühlkörper spendieren.

Meiner läuft nun auch vollständig und vor allem SCHNELL

Ein reinstall.sh war das Zauberwort.

Beim Umzug vom Pi hat er da wohl irgendwas verschluckt.

Hatte versucht per Backitup ein komplett Image als Umzugshilfe zu verwenden.

Jetzt läuft es auf alle Fälle (auch BLE und der JeeLink)

Schönen Abend noch allen

Gruß Peer

bimmi

Also komischerweise kann ich keine .sh bash ausführen. Kenn ich gar nicht…

habe ihn mit Kühlkörper und selbst dann läuft er mit über 60°. Hatte vorher schon kurzzeitig 71°C. Mal sehen. Drucke gerade das Gehäuse von Thingiverse https://www.thingiverse.com/thing:2905485 und werde ihm wohl einen Lüfter verpassen ;)

Richte gerade alles neu ein. Das Backup lässt sich irgendwie nicht einspielen :(

Schönen Abend ebenfalls!

C1500

Was kommt denn für eine Meldung?

Hab hier den entscheidenden Tip gefunden: http://www.iobroker.net/docu/?page_id=5106&lang=de

sollte jedoch eine Meldung kommen

-bash: ./reinstall.sh: /bin/bash^M: bad interpreter: No such file or directory

muss die Datei reinstall.sh auf Linux-Zeilenende umgewandelt werden.
Das geht mit Notepad++ oder auf der Kommandozeile mit diesen Befehlen (danke an paul53)

mv /opt/iobroker/reinstall.sh /opt/iobroker/reinstall.dos

tr -d '\r' < /opt/iobroker/reinstall.dos > /opt/iobroker/reinstall.sh

Jetzt noch ein

iobroker start

Da fehlt noch das abschließende ausführen von ./reinstall.sh und dann erst iobroker start.

Das mit dem Backup vom Pi hat auch nicht sofort geklappt.

Am besten ging es so:

Auf dem alten System Backitup komplett Backup erstellen
Auf neuem System ioBroker installieren und auch hier Backitup (Ich hatte keine weiteren Adapter)
Dann Backup wie in Backitup wieder schreiben
./reinstall.sh um alles lauffähig zu bekommen.

So zumindest hätte es bei mir schneller geklappt ;o)

Gruß Peer

PS: Wenn schon gehäuse dann aber bitte das https://www.pine64.org/?product=rock64-premium-aluminum-casing

Das sieht wenigstens so Edel aus wie der Rock64 ist ;o)

~~![](</s><URL url=)<link_text text="https://www.pine64.org/wp-content/uploa ... -Case1.jpg">https://www.pine64.org/wp-content/uploads/2018/08/Rock64-Al-Case1.jpg</link_text>" />~~

bimmi

ah das war der entscheidende Tip. Danke sehr :) Jetzt klappt das mit der reinstall.sh!

Ja, das Alu Gehäuse ist schon wirklich fein jedoch bin ich mit dem Drucker etwas flexibler. Habe mir die Stromversorgung direkt an den Rock64 gelötet und müsste jetzt in das schöne Alu Gehäuse bohren :(

C1500

Im BLE Threat kam gerade genau der passende Tip warum der Umzug so problematisch ist.

Ist ja auch vollkommen Logisch

Nur blöd wenn man vor lauter Bäumen den Wald nicht sieht.

Pi3 = 32 BIt

Rock64 = 64 Bit (Steht ja schon im Namen) lol

Da hilft dann eh nur ein ./reinstall.sh

Community Forum

NEWS

ROCK64 - Pine64

Support us

605

32.4k

81.5k

1.3m