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

Hi @FrankM , danke dir. Richtig, falschen Link zum Ayufan-Image gepostet. Ich bin gerade am ersten Testen mit dem 4.4er Armbian. Auf den ersten Blick scheint alles gut zu laufen. Positiv ist mir gleich einmal die I/O aufgefallen (128gb Samsung Evo Plus), offensichtlich kann man diese gut ausreizen. Zudem bin ich ebenso vom armbian-config begeistert, Plex und OMV laufen prima. Bis jetzt hab ich mich mit armbian eher mit nanopi&co herumgeschlagen, wo das kein Thema war. Leider habe ich offensichtlich vergessen die PCIe-Sata mitzubestellen, insofern musste ich mir nun eine beim großen A bestellen. Ich berichte dann gerne ausführlich darüber sobald bei mir alles läuft. Grüße, Flow

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.

@ffgghhtt Hallo, ich bin doch tatsächlich immer noch auf A2 Aber, BIOS Update ist immer so mühsam. Meine Kiste ist, wenn ich sie ausmache, zu 99% in Bereitschaft. Die wird nur komplett durchgestartet, wenn es einen neuen Kernel gibt o.ä. Ich muss da aber mal dran

@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

hello, most likely a module will not do it, I guess. Assume the kernel wants to "load" the root. It needs to know lvm functionality for this, in case the root is in a lvolume. Unfortunately, that module is located in (exactly) that lvolume. In my understanding, here's where the initrd comes into play. But i might be wrong regards

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!

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.

@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.

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ß

@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