0.6.60 released 0.6.60: Fix pcie/nvme/sata support for 4.4, 0.6.60: Fix spi-flash access for 4.4/mainline, Ich bin davon ausgegangen, das 0.6.x nict mehr fortgeführt wird, okay - sieht nicht so aus. Sollte released werden, ist aber aus irgendeinem Grund gestern nicht passiert (lt. Kamil)

4.20.0-1090-ayufan released Änderungen -> https://gitlab.com/ayufan-repos/rock64/linux-mainline-kernel/commits/master

Ayufan Images nutzen user: rock64 pw: rock64

0.8.3: gitlab-ci-linux-build-141 released 0.8.2: Be more strict what packages/kernels are being in use for 0.8.x branch, 0.8.1: The final pre-release, Kamil hat diesen Release als Latest release gekennzeichnet. Das heißt man kann jetzt vorhandenen Installationen auf diesen Build upgraden. # Pick one sudo apt-get update -y && sudo apt-get install linux-rock64-0.8 -y sudo apt-get update -y && sudo apt-get install linux-rockpro64-0.8 -y sudo apt-get update -y && sudo apt-get install linux-pinebookpro-0.8 -y # Upgrade all other packages sudo apt-get update -y && sudo apt-get dist-upgrade -y # Remove invalid X11 config, and fix bootloaders sudo rm /etc/X11/xorg.conf.d/20-armsoc.conf sudo new_extlinux_boot.sh rootfs sudo rock64_upgrade_bootloader.sh Quelle: https://github.com/ayufan-rock64/linux-build/releases/tag/0.8.3 Kamil ist wohl jetzt mit dem Build so weit zufrieden Ich wüßte auch nicht wo es jetzt noch richtig klemmt. Eine Sache funktioniert noch nicht perfekt. PXE Boot USB3 Boot Aber Kamil hat im IRC geschrieben, das er das als nächstes in Angriff nehmen will.

In der Zwischenzeit verweise ich gerne auf Kamil's 5.0 Kernel https://github.com/ayufan-rock64/linux-mainline-kernel/releases

@FrankM Exakt

Danke soweit für den Support. Wird sicher nicht das letzte Mal bleiben das ich hier vorbeischaue....

Okay .. also .. zusammengefasst: Booten von emmc geht nicht (auch nicht armbian) booten von spi geht / geht nicht ? .. bzw. siehst du in der seriellen ob er PXE boot initiert ? (sofern du ein ayufan spi tool eingespielt hat (dies war oben über die spi-flash bzw. spi-erase tools angedacht) booten von sd karte geht und die emmc ist sichtbar ... ich gehe mal davon aus, dass der jumper neben der emmc nicht gesetzt ist .. weil der ist für das (globale) abschalten der emmc zuständig .. (dann wäre die emmc aber auch nicht nach dem booten sichtbar ...) Latein am Ende .. ggf. noch booten über usb 2 testen .. (usb 3 - geht nicht bzw. nicht mit jedem device, bzw. nicht stabil ...) deswegen .. usb 2 .. ist es eine 2.0 oder 2.1 edition ? bei der 2.0 .. gab es etwas wegen der PCIe timing .. widerstand entfernen ..oder so ..) Bootorder ist lt. meinem wissen (fyi) SPI Flash -> eMMC -> SD -> USB .. sofern noch garantie .. ggf. zum händler tauschen schicken .. der aufwand fürs testen überschreitet auch alle "wirtschaftlichen" kosten Alternativ .. die emmc als root laufwerk ummappen (anleitung hier im forum) und von einer billig sd karte booten. problem beim kernel update bzw. muss dann manuell nachgeholt werden. oder .. pxe booten einrichten .. sofern der spi boot dir ein pxe boot anzeigt .. zu dem spi booten info / ablauf hier noch ein link !! achtung diese ist für den ROCK64 !! also nicht diese images nehmen .. sondern die vom oberen link: https://github.com/ayufan-rock64/linux-build/blob/master/recipes/flash-spi.md Latein ende

Ich habe heute, nachdem es einige Updates von Armbian gab, mal nachgeschaut ob ein spezieller Fehler verschwunden ist. Und zwar geht es um das Resizen der Partion nachdem wir Armbian auf eine USB-HDD (USB3) installiert haben. Ich setze dafür folgendes System ein. Hardware ROCKPro64v2.0 4GB RAM SanDisk 240GB 2,5 Zoll HDD (nix tolles) Software Welcome to ARMBIAN 5.67.181217 nightly Debian GNU/Linux 9 (stretch) 4.4.167-rockchip64 Was sehe ich nach dem Reboot? root@rockpro64:~# df -h Filesystem Size Used Avail Use% Mounted on udev 1.9G 0 1.9G 0% /dev tmpfs 388M 5.3M 383M 2% /run /dev/sda1 220G 1.3G 207G 1% / tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup tmpfs 1.9G 4.0K 1.9G 1% /tmp /dev/mmcblk0p1 58G 1.3G 57G 3% /media/mmcboot /dev/zram0 49M 3.0M 43M 7% /var/log tmpfs 388M 0 388M 0% /run/user/0 Korrekt die Größe angepasst! Schnell mal den USB3 testen root@rockpro64:~# sudo dd if=/dev/zero of=sd.img bs=1M count=4096 conv=fdatasync 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 38.0723 s, 113 MB/s Der Adapter root@rockpro64:~# lsusb -vvv Bus 004 Device 002: ID 2109:0715 VIA Labs, Inc. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 3.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x2109 VIA Labs, Inc. idProduct 0x0715 bcdDevice 1.31 iManufacturer 1 VLI Manufacture String iProduct 2 VLI Product String iSerial 3 000000123ADA bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 121 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 224mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 1 bNumEndpoints 4 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 98 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Command pipe (0x01) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 MaxStreams 32 Data-in pipe (0x03) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x06 EP 6 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 MaxStreams 32 Data-out pipe (0x04) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x87 EP 7 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 MaxStreams 32 Status pipe (0x02) Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 70 bNumDeviceCaps 4 FIXME: alloc bigger buffer for device capability descriptors Device Status: 0x0000 (Bus Powered) Ein lästiger Fehler weniger.

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ß

Dann nochmals vielen Dank!

@Northstar Hallo, laut meinen Info's nicht, hat irgendwas mit der Speicheradressierung zu tuen. Und Grafikkarten benötigen wohl zu viel. Das ist das, was ich bei den vielen Diskussionen im IRC so aufgeschnappt habe. Ich habe es auch schon mal genauso probiert - natürlich ohne Erfolg.

Erster dicker Fehlschlag mit Armbian Heute versucht mein NAS mit Armbian aufzusetzen. Raid einbinden usw. kein Problem. Als es dann an Restic und GO ging war es vorbei mit lustig. Pakete zu alt, Quellen eingebunden und nur noch Fehler. Hmm!? Da ich nach zwei Stunden keine Lust mehr hatte, habe ich das erst mal auf Eis gelegt. Manchmal ist es besser an einem anderen Tag noch mal von vorne anzufangen. Nun läuft das NAS wieder mit rock64@rockpro64v_2_1:~$ uname -a Linux rockpro64v_2_1 4.19.0-rc4-1071-ayufan-g10a63ec6c2a2 #1 SMP PREEMPT Mon Oct 1 07:33:40 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux So schlecht läuft das ja nicht, wenn denn mal die USB3 Schnittstelle vernünftig laufen würde. Update: Manchmal muss man es auch richtig machen https://forum.frank-mankel.org/topic/420/rockpro64-armbian-go-restic-installieren

heho, das kann ich bestätigen: kein gerät eingesteckt, keine bridge sichtbar im lspci. die kernelmodule (pcie_rockchip_host, nvme_core, nvme) werden anscheinend aber schon geladen, also irgendwer ist anscheinend da. mir ist noch unklar wie man heraus kriegt, wer das sein könnte. Geholfen hat setpci da auch nicht bislang hab aus spaß mal eine karte gesteckt die nicht geht (also issue https://github.com/rockchip-linux/kernel/issues/116, zufällig genau die im letzten kommentar) da streikt denn alles: lspci -vvvxxx pcilib: Cannot open /sys/bus/pci/devices/0000:00:00.0/config lspci: Unable to read the standard configuration space header of device 0000:00:00.0 mein sys: Linux 4.20.0-gentoo #20 SMP PREEMPT Sun Jan 20 15:42:02 CET 2019 aarch64 GNU/Linux gruß

@elRadix : With pine64 sata-card you can use two hdd's. https://www.pine64.org/?product=rockpro64-pci-e-to-dual-sata-ii-interface-card For working cards please look into this thread before you buy anything.

@Hercemania sagte in Lüftersteuerung Kernel 4.20: kann man so etwas automatisieren? Du kannst dir ein Script schreiben oder statt make install das Programm checkinstall nutzen um ein Paket zu generieren. Anschließend kann man es mit checkinstall installieren bzw. deinstallieren um eine aktuellere Version zu erhalten. Aber ich denke ein Script für git pull make checkinstall -D make install dpkg -i <paketname> wäre schon mit Kanonen auf Spatzen geschossen.