Skip to content

ROCKPro64 - Reset per SSH funktioniert nicht (Kernel 4.4.x)

ROCKPro64
  • Mit Kernel 4.4.154-1122 funktioniert ein

    sudo reboot now
    

    nicht! Folgender Fehler taucht dann auf

    U-Boot SPL 2017.09-rockchip-ayufan-1033-gdf02018479 (Aug 06 2018 - 22:29:15)    
    booted from SD                                                                  
    Trying to boot from MMC2                                                        
    mmc_load_image_raw_sector: mmc block read error                                
    SPL: failed to boot from all boot devices                                      
    ### ERROR ### Please RESET the board ###
    

    Logfile -> https://pastebin.com/ysghzKnb

    Der Resettaster auf der Platine funktioniert wie erwartet.

    Mit Kernel 4.19.0-rc4-1071 taucht der Fehler nicht auf.

    Ich habe mal einen Issue auf github.com aufgemacht.

    Danke @Jens, der Fehler ist mir auch schon länger aufgefallen. Aber durch Deine EMail kam der Anstoß, die Sache nochmal ausführlich zu testen!

  • Der Fehler ist mit dem Release von Image 0.7.11 gefixt.

  • Hallo Frank,

    danke für Deine Unterstützung. Bin jetzt auf dem aktuellen Release, habe aber leider weiterhin das gleiche Problem. Image liegt auf einer SD Karte.
    Frage: Wo sehe ich denn das Log File zum nachschauen?

    Grüße
    Jens

  • Hast du nur den Kernel ausgetauscht oder ein komplett neues Image benutzt? Weil ich nicht 100% sicher bin, ob da nicht noch andere Sachen geändert wurden.

    Du kannst mal in die Konsole folgendes eingeben

    dmesg
    

    Da sieht man eigentlich alles Wichtige beim Startvorgang. Ok, die u-boot Meldungen sieht man nur mit der seriellen Konsole. Benutzt du eine serielle Konsole?

    Wenn möglich, mal das 0.7.11 auf eine SD_Karte und damit starten.

  • Ich habe eben mal gerade nachgesehen, der u-boot im Image 0.7.10 ist ein anderer als in 0.7.11
    Und dort wird auch das Problem herkommen (Vermutung).

    Also muss man zwingend ein neues Image benutzen, oder man weiß wie man den u-boot auf einer bestehenden Installation ersetzt. Interessantes Thema für einen neuen Beitrag, oder!?

    u-boot

    0.7.11

    2017.........1033
    

    0.7.10

    2017.........1025
    
  • Hallo Frank,
    so bin jetzt endlich dazu gekommen deine Vorschläge auszuprobieren. Neue SD Karte, 0.7.11 draufgeklatscht, beide akt. Kernels ausprobiert. Ohne Erfolg. Liegt vllt. daran, das mein U-Boot noch jungfräulich ist. Werde ich bei Gelegenheit mal flashen und dann berichten.

    Danke dir auf alle Fälle
    Grüße
    Jens

  • Wo ist denn dein u-boot? Im SPI?

  • Hatte ich wie gesagt noch gar nicht geflasht. Out of the box Image drauf und Kernel Update

  • Ok, dann verstehe ich jetzt nicht, wieso der Reboot nicht funktioniert!?!?!?

    Hast du eine UART-Verbindung um den Bootvorgang zu beobachten?

  • Noch nicht...Aber vielleicht hilft ja ein U-Boot flash. Halte dich auf dem laufenden.

  • So, also erst wenn UBoot drauf ist klappts auch mit dem Reset Jetzt bin ich ein Stück weiter.

    Danke Dir

  • Hallo zusammen,
    habe mir den Rockpro64 jetzt neu angeschafft und das aktuelle Openmediavault (7.11 arm64) auf SD Karte geschrieben. Leider habe ich auch das genannte Problem mit dem reboot.
    Jetzt habe ich probiert das U-Boot auf SPI zu flashen. Denke auch, dass es funktioniert hat (blinken der weissen led).

    Leider funktioniert der reboot nicht. Mache ich was falsch?

    Danke und Gruss

  • Willkommen @killlah78

    Das mit dem Reboot auf dem RockPro64 ist ein leidiges Thema, mal klappt es, mal nicht. Woran es liegt, weiß ich nicht zu 100%, es soll aber wohl an Timingproblemen im Zusammenhang SD-Karte und u-boot liegen.

    Ich habe hier aktuell eine Testinstallation vom Kamil

    rock64@rockpro64:~$ uname -a
    Linux rockpro64 4.4.154-1124-rockchip-ayufan-ged3ce4d15ec1 #1 SMP Mon Oct 22 20:59:41 UTC 2018 aarch64 GNU/Linux
    

    Ich boote dort von SD-Karte und es steckt noch eine PCIe NVMe Karte drin. Als ich eben mehrmals gebootet habe klappte das einwandfrei. Ok, das hilft dir nicht.

    Aber den u-boot in den SPI zu flashen ist auch keine Lösung. Das dient übrigens dazu, von USB oder PXE zu booten, die SD-Karte hat immer noch Vorrang. Der SPI würde erst dann greifen, wenn keine SD-Karte und kein eMMC-Modul verbaut ist. Ändert also nichts am Problem.

    Du hast zwei Möglichkeiten, einmal mit einer hochwertigen SD-Karte testen und einmal mit dem Problem leben. Hier in meinem Fall, teste ich mit den Boards meistens nur rum (sind mir noch zu viele Macken USB3, SATA), da ist es dann kein Problem nach einem erfolgten Reboot mal kurz den Reboot-Taster auf der Platine zu betätigen.

    Ich kann dich aber verstehen, es nervt ein wenig 🙂

  • halli hallo & zusammen,
    in Allgemeinen lässt sich selten empfehlen, auf verdacht alles zu updaten, sobald irgend etwas nicht tut. Oftmals holt man sich lediglich neue Ungewissheit ins Boot. Es hilft eher zu wissen, wo es (denn ungefähr) hakt.

    Wie Frank in etwa bereits angesprochen hat ist es ungemein hilfreich zu sehen "was ab geht". Sprich die serielle "Schnitte" anzuklemmen. Das ist wirklich kein Hexenwerk, braucht aber einen Pegelwandler.
    Andernfalls ist die Gefahr hoch, dass man mit Rätselraten einen Abend ohne Ergebnis in den Sand setzt. Hab ich einmal mit diesem Board hinter mir, dann die serielle Komm angeklemmt.
    Ein ResetProb hab ich zumindest mit eMMC noch nicht beobachtet. Dabei habe ich viel Kernel gewechselt (nie den uboot) und 'reboot' getippt. Ab und an hängt er anscheinend bei Initialisierung der tty's, aber ich mag mich irren. Für das Prob von @killlah78 fehlt für mehr einfach ein output
    gruß

  • ROCKPro64 - Debian Bullseye Teil 1

    ROCKPro64
    17
    0 Stimmen
    17 Beiträge
    2k Aufrufe
    FrankMF

    Durch diesen Beitrag ist mir mal wieder eingefallen, das wir das erneut testen könnten 😉

    Also die aktuellen Daten von Debian gezogen. Das Image gebaut, könnt ihr alles hier im ersten Beitrag nachlesen. Da die eingebaute Netzwerkschnittstelle nicht erkannt wurde, habe ich mal wieder den USB-to-LAN Adapter eingesetzt.

    Bus 005 Device 002: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet

    Die Installation wollte ich auf einem NVMe Riegel installieren.

    Die Debian Installation durchgezogen und nach erfolgreicher Installation neugestartet. Und siehe da, ohne das man alles möglich ändern musste, bootete die NVMe SSD 🤓

    Eingesetzter uboot -> 2020.01-ayufan-2013......

    Die nicht erkannte LAN-Schnittstelle müsste an nicht freien Treibern liegen, hatte ich da irgendwo kurz gelesen. Beim Schreiben dieses Satzes kam die Nacht und ich konnte noch mal drüber schlafen. Heute Morgen, beim ersten Kaffee, dann noch mal logischer an die Sache ran gegangen.

    Wir schauen uns mal die wichtigsten Dinge an.

    root@debian:~# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 62:03:b0:d6:dc:b3 brd ff:ff:ff:ff:ff:ff 3: enx000acd26e2c8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:0a:cd:26:e2:c8 brd ff:ff:ff:ff:ff:ff inet 192.168.3.208/24 brd 192.168.3.255 scope global dynamic enx000acd26e2c8 valid_lft 42567sec preferred_lft 42567sec inet6 fd8a:6ff:2880:0:20a:cdff:fe26:e2c8/64 scope global dynamic mngtmpaddr valid_lft forever preferred_lft forever inet6 2a02:908:1260:13bc:20a:xxxx:xxxx:xxxx/64 scope global dynamic mngtmpaddr valid_lft 5426sec preferred_lft 1826sec inet6 fe80::20a:cdff:fe26:e2c8/64 scope link valid_lft forever preferred_lft forever

    Ok, er zeigt mir die Schnittstelle eth0 ja an, dann kann es an fehlenden Treibern ja nicht liegen. Lässt dann auf eine fehlerhafte Konfiguration schließen. Nächster Halt wäre dann /etc/network/interfaces

    Das trägt Debian ein

    # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug enx000acd26e2c8 iface enx000acd26e2c8 inet dhcp # This is an autoconfigured IPv6 interface iface enx000acd26e2c8 inet6 auto

    Gut, bei der Installation hat Debian ja nur die zusätzliche Netzwerkschnittstelle erkannt, folgerichtig ist die auch als primäre Schnittstelle eingetragen. Dann ändern wir das mal...

    # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback # The primary network interface #allow-hotplug enx000acd26e2c8 allow-hotplug eth0 #iface enx000acd26e2c8 inet dhcp iface eth0 inet dhcp # This is an autoconfigured IPv6 interface #iface enx000acd26e2c8 inet6 auto iface eth0 inet6 auto

    Danach einmal alles neu starten bitte 😉

    systemctl status networking

    Da fehlte mir aber jetzt die IPv4 Adresse, so das ich einmal komplett neugestartet habe. Der Ordnung halber, so hätte man die IPv4 Adresse bekommen.

    dhclient eth0

    Nachdem Neustart kam dann das

    root@debian:/etc/network# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 62:03:b0:d6:dc:b3 brd ff:ff:ff:ff:ff:ff inet 192.168.3.172/24 brd 192.168.3.255 scope global dynamic eth0 valid_lft 42452sec preferred_lft 42452sec inet6 fd8a:6ff:2880:0:6003:b0ff:fed6:dcb3/64 scope global dynamic mngtmpaddr valid_lft forever preferred_lft forever inet6 2a02:908:1260:13bc:6003:xxxx:xxxx:xxxx/64 scope global dynamic mngtmpaddr valid_lft 5667sec preferred_lft 2067sec inet6 fe80::6003:b0ff:fed6:dcb3/64 scope link valid_lft forever preferred_lft forever 3: enx000acd26e2c8: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 00:0a:cd:26:e2:c8 brd ff:ff:ff:ff:ff:ff

    Fertig, eth0 läuft. Nun kann man den zusätzlichen Adapter entfernen oder halt konfigurieren, wenn man ihn braucht.

    Warum der Debian Installer die eth0 nicht erkennt verstehe ich nicht, aber vielleicht wird das irgendwann auch noch gefixt. Jetzt habe ich erst mal einen Workaround um eine Installation auf den ROCKPro64 zu bekommen.

  • linux-mainline-u-boot

    Angeheftet Images
    2
    0 Stimmen
    2 Beiträge
    380 Aufrufe
    FrankMF

    2020.01-ayufan-2014-gff2cdd38 released

    ayufan: rockchip: allow to boot scsi4, as JMS585 can have 5 drives
  • VON USB 4TB HD BOOTEN GEHT NICHT

    ROCKPro64
    5
    0 Stimmen
    5 Beiträge
    576 Aufrufe
    W

    Hallo FrankM,
    schade das Du mir nicht weiter helfen kannst, aber danke für Deine schnelle Antwort.
    Mit dem Bugreport kenne ich nicht aus, bin noch leihe.

    Einen schönen Abend noch.

    Winne

  • SATA Karte Marvell 88SE9230 Chipsatz

    Angeheftet Hardware
    19
    0 Stimmen
    19 Beiträge
    6k Aufrufe
    FrankMF

    Ok, es gibt noch eine andere Möglichkeit.

    Kamil hat mir noch ein wenig geholfen. Mit folgender Änderung werden die Platten gefunden.

    hmm, I had to add /etc/default/extlinux: libahci.skip_host_reset=1

    Sieht dann so aus.

    # Configure timeout to choose the kernel # TIMEOUT="10" # Configure default kernel to boot: check all kernels in `/boot/extlinux/extlinux.conf` # DEFAULT="kernel-4.4.126-rockchip-ayufan-253" # Configure additional kernel configuration options APPEND="$APPEND root=LABEL=linux-root rootwait rootfstype=ext4 libahci.skip_host_reset=1"

    Danach waren die Platten zu sehen.

    root@rockpro64:/tmp/etc/default# blkid /dev/sda2: SEC_TYPE="msdos" LABEL_FATBOOT="boot-efi" LABEL="boot-efi" UUID="ABCD-FC7D" TYPE="vfat" PARTLABEL="boot_efi" PARTUUID="72e36967-4050-4bb3-8f8f-bf6755c38f28" /dev/sda3: LABEL="linux-boot" UUID="8e289a3e-0f9b-4da1-a147-51e03390637c" TYPE="ext4" PARTLABEL="linux_boot" PARTUUID="fe944fd2-3e42-4202-8a95-656e9bdb4be6" /dev/sda4: LABEL="linux-root" UUID="3e9513c6-dfd1-48c9-bee2-04bb5a153056" TYPE="ext4" PARTLABEL="linux_root" PARTUUID="d2d1dd88-030d-4f74-998f-7c9ce7d385d0" /dev/sdb2: SEC_TYPE="msdos" LABEL_FATBOOT="boot-efi" LABEL="boot-efi" UUID="56C9-F745" TYPE="vfat" PARTLABEL="boot_efi" PARTUUID="919c8f73-5f25-4a01-9072-3a5ed9a88ff2" /dev/sdb3: LABEL="linux-boot" UUID="23c19647-f4a1-4197-a877-f1bb03456bef" TYPE="ext4" PARTLABEL="linux_boot" PARTUUID="093d0cc0-d122-4dce-aeb5-4e266b4b7d9d" /dev/sdb4: LABEL="linux-root" UUID="f1c74331-8318-4ee8-a4f7-f0c169fb9944" TYPE="ext4" PARTLABEL="linux_root" PARTUUID="964ab457-58d5-40c4-bb02-dfd37bd2f0da" /dev/sda1: PARTLABEL="loader1" PARTUUID="37466429-e4a4-495c-b9a1-3f74625a3cae" /dev/sdb1: PARTLABEL="loader1" PARTUUID="33f692b3-54cb-4a37-b602-21a2baf32fa0"

    Aber auch hiermit ist ein Boot von der SATA Platte nicht möglich.

    Ich möchte hier noch was vom kamil zitieren.

    (11:44:09) ayufanWithPM: will look later, but this controller is tricky, also on x86 as well
    (11:44:16) ayufanWithPM: jms585 seems to be significantly more stable

    Evt. bekommt er das gefixt 😉

  • Image 0.6.57 - NVMe paar Notizen

    Verschoben Archiv
    1
    0 Stimmen
    1 Beiträge
    651 Aufrufe
    Niemand hat geantwortet
  • ROCKPro64 - Der Bootvorgang

    Verschoben Hardware
    3
    0 Stimmen
    3 Beiträge
    2k Aufrufe
    FrankMF

    Um einen neuen Kernel booten zu können, brauche ich diese 4 Dateien unter /boot

    config-4.19.0-rc4-1065-ayufan-g72e04c7b3e06 initrd.img-4.19.0-rc4-1065-ayufan-g72e04c7b3e06 System.map-4.19.0-rc4-1065-ayufan-g72e04c7b3e06 vmlinuz-4.19.0-rc4-1065-ayufan-g72e04c7b3e06

    Und den Ordner /boot/dtbs/4.19.0-rc4-1065-ayufan-g72e04c7b3e06 mit folgendem Inhalt

    rock64@rockpro64v2_0:/boot/dtbs/4.19.0-rc4-1065-ayufan-g72e04c7b3e06$ ls -la total 104 drwxr-xr-x 26 root root 4096 Sep 30 09:54 . drwxr-xr-x 6 root root 4096 Sep 30 09:55 .. drwxr-xr-x 2 root root 4096 Sep 30 09:54 al drwxr-xr-x 2 root root 4096 Sep 30 09:54 allwinner drwxr-xr-x 2 root root 4096 Sep 30 09:54 altera drwxr-xr-x 2 root root 4096 Sep 30 09:54 amd drwxr-xr-x 2 root root 4096 Sep 30 09:54 amlogic drwxr-xr-x 2 root root 4096 Sep 30 09:54 apm drwxr-xr-x 2 root root 4096 Sep 30 09:54 arm drwxr-xr-x 4 root root 4096 Sep 30 09:54 broadcom drwxr-xr-x 2 root root 4096 Sep 30 09:54 cavium drwxr-xr-x 2 root root 4096 Sep 30 09:54 exynos drwxr-xr-x 2 root root 4096 Sep 30 09:54 freescale drwxr-xr-x 2 root root 4096 Sep 30 09:54 hisilicon drwxr-xr-x 2 root root 4096 Sep 30 09:54 lg drwxr-xr-x 2 root root 4096 Sep 30 09:54 marvell drwxr-xr-x 2 root root 4096 Sep 30 09:54 mediatek drwxr-xr-x 2 root root 4096 Sep 30 09:54 nvidia drwxr-xr-x 2 root root 4096 Sep 30 09:54 qcom drwxr-xr-x 2 root root 4096 Sep 30 09:54 renesas drwxr-xr-x 2 root root 4096 Sep 30 09:54 rockchip drwxr-xr-x 2 root root 4096 Sep 30 09:54 socionext drwxr-xr-x 2 root root 4096 Sep 30 09:54 sprd drwxr-xr-x 2 root root 4096 Sep 30 09:54 synaptics drwxr-xr-x 2 root root 4096 Sep 30 09:54 xilinx drwxr-xr-x 2 root root 4096 Sep 30 09:54 zte

    Unter /boot/extlinux liegt dann die Datei extlinux.conf

    Die sieht bei mir dann so aus

    timeout 10 menu title select kernel label kernel-4.19.0-rc4-1065-ayufan-g72e04c7b3e06 kernel /boot/vmlinuz-4.19.0-rc4-1065-ayufan-g72e04c7b3e06 initrd /boot/initrd.img-4.19.0-rc4-1065-ayufan-g72e04c7b3e06 devicetreedir /boot/dtbs/4.19.0-rc4-1065-ayufan-g72e04c7b3e06 append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=TEST rootwait rootfstype=ext4 label kernel-4.19.0-rc4-1065-ayufan-g72e04c7b3e06-memtest kernel /boot/vmlinuz-4.19.0-rc4-1065-ayufan-g72e04c7b3e06 initrd /boot/initrd.img-4.19.0-rc4-1065-ayufan-g72e04c7b3e06 devicetreedir /boot/dtbs/4.19.0-rc4-1065-ayufan-g72e04c7b3e06 append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=TEST rootwait rootfstype=ext4 memtest

    Darunter kommen dann evt. die alten Kernel die installiert waren, das habe ich hier im Beispiel weg gelassen.

  • Vorserienmodell

    ROCKPro64
    1
    0 Stimmen
    1 Beiträge
    532 Aufrufe
    Niemand hat geantwortet
  • Wiki zum ROCKPro64 veröffentlicht!

    Verschoben ROCKPro64
    1
    0 Stimmen
    1 Beiträge
    1k Aufrufe
    Niemand hat geantwortet