Skip to content

Images 0.7.x

Images
22 2 3.0k 1
  • 0.7.3 released

    • 0.7.3: Fix generation of extlinux.conf (linux booting),
    • 0.7.2: Pin packages,
    • 0.7.2: Improve performance of build process,
    • 0.7.1: Use GitLab CI for releasing all images,
    • 0.7.0: Introduces heavy refactor splitting all components into separate repos, and separate independent releases (u-boot, kernel, kernel-mainline, compatibility package),
    • 0.7.0: Dry run everything,

    Kamil hat seinen kompletten Build-Prozeß umgebaut. Diese 0.7.3 Version bootet (nur ohne PCIe NVMe-Karte). Außerdem habe ich Unstabilitäten über die LAN-Schnittstelle bemerkt (Freeze). Nicht empfehlenswert, im Moment.

  • 0.7.4 released

    • 0.7.4: Fix resize_rootfs.sh script to respect boot flags (fixes second boot problem introduced by 0.7.0),
    • 0.7.4: Add rock(pro)64_erase_spi_flash.sh,
    • 0.7.4: Fix cursor on desktop for rockpro64,

    Bootet nur ohne PCIe NVMe Karte! Kamil will das Fixen.

  • 0.7.5 released

    • 0.7.5: Various stability fixes for kernel and u-boot,
    • 0.7.5: Added memtest to kernels and extlinux,
    • 0.7.5: Show early boot log when booting kernels,

    Kurzer Test - bootet jetzt mit PCIe NVMe Karte

  • 0.7.6 released

    • 0.7.6: Change OPP's for Rock64 and RockPro64: ayufan-rock64/linux-kernel@4.4.132-1059-rockchip-ayufan...ayufan-rock64:4.4.132-1062-rockchip-ayufan,

    Soll mehr Stabilität bringen, macht es leider nicht. So langsam wird es ärgerlich, das mit jedem Release nichts nach vorne geht.

  • 0.7.7 released

    • 0.7.7: Fix memory corruptions caused by Mali/Display subsystem (4.4),
    • 0.7.7: Enable SDR104 mode for SD cards (this requires u-boot upgrade if booting from SD),

    Langsam wird es, kann man jetzt zig mal booten ohne Probleme. Einziges Problem was ich im Moment nach einem kurzen Test festgestellt habe, das Erkennen der NVMe Karte ist Zufall und gelingt nur selten. Seltsamerweise im Mainline kein Problem!?

    Kamil hat das für 4.4 gefixt -> https://github.com/ayufan-rock64/linux-kernel/commit/bfb0d6c371d14b0d1fc60326b9bc84985a26f848?diff=unified

    Hier gibt es den Kernel zum herunter laden -> https://github.com/ayufan-rock64/linux-kernel/releases/tag/4.4.132-1070-rockchip-ayufan

  • 0.7.8 released ✌

    • 0.7.8: Improve eMMC compatibility on RockPro64,
    • 0.7.8: Disable sdio (no wifi/bt) to fix pcie/nvme support on 4.4 for RockPro64,
    • 0.7.8: Fix OMV builds (missing initrd.img),
    • 0.7.8: Make all packages virtual, conflicting and replacing making possible to do linux-rock64/rockpro64 to replace basesystem,

    (22:32:51) ayufan1: pushed one final release before vacations
    (22:32:59) ayufan1: consider this one to be the future release
    (22:33:15) ayufan1: if people do confirm that they do work on rockpro64 and rock64 I will make it finally stable 🙂
    (22:33:21) ayufan1: it is probably the best support so far
    (22:33:48) ayufan1: not yet the most performant (for rockpro64), I had to limit in bunch of places freqs, disable stuff, but it should be stable and support base ops
    (22:34:01) ayufan1: but, first stability, then we gonna add extra stuff

    Kamil macht Urlaub, da haben wir ja ein wenig Freizeit 🙂

  • 0.7.9 released

    • 0.7.9: Fix upgrade problem (u-boot-* packages),

    Kamil macht Urlaub 😂 Ok, es gab wohl ein paar kleinere Probleme die Platinen upzugraden. Kamil hat noch schnell die Probleme gefixt und das 0.7.9 Image veröffentlicht.

  • 0.7.10 released

    • 0.7.10: Rebased rockchip and mainline kernels,
    • 0.7.10: Support USB gadgets for rock/pro64,
    • 0.7.10: Disable TX checksumming for RockPro64,
    • 0.7.10: Improve FAN for RockPro64,
    • 0.7.10: Improve sdmmc0 stability for Rock64,
    • 0.7.10: Enable binfmt-misc,
    • 0.7.10: Improve stability of PCIE for RockPro64,
    • 0.7.10: Fix eMMC stability on RockPro64 mainline kernel,

    Die Container Images fehlen, Kamil hatte da ein Problem mit. Deshalb auch die Kennzeichnung als Pre-Release.

  • Die Container-Images für 0.7.10 sind jetzt auch fertig!

  • 0.7.11 released ✌

    • 0.7.11: Rebased mainline kernel,
    • 0.7.11: Run rockchip kernel at 250Hz to increase performance,
    • 0.7.11: Add support for usb gadgets for rockchip,
    • 0.7.11: Introduce change-default-kernel.sh script to easily switch between kernels,
  • 0.7.12 released

    • 0.7.12: Rebased mainline kernel,
    • 0.7.12: Rockchip kernel has patches for enabling sdio0 and pcie concurrently,
    • 0.7.12: A bunch of dependencies updates,
  • Ich kann 0.7.12 nicht empfehlen. Bei der Installation eines Systems mit PCIe NVMe SSD auf einem ROCKPro64 v2.0 4GB RAM habe ich folgenden Fehler gehabt.

    Danach war die Partition auf der SSD weg.

    Ich bin jetzt wieder auf 0.7.11 mit dem letzten Kernel der funktioniert 4.4.154-1128-rockchip-ayufan

    Dran denken, was ich mit diesem Zeichen ✌ kennzeichne, funktioniert.

  • 0.7.13 released

    • 0.7.13: Enable support for RockPro64 WiFi/BT module,
    • 0.7.13: Fix LXDE build: updated libdrm,

    PCIe NVMe SSD & WiFi = Crash!
    WiFi alleine habe ich bei einem kurzen Test auf stretch minimal zum Laufen bekommen - aber unstabil!

    Alles in allem, noch viel Arbeit. Nur für Leute mit Spaß am Testen geeignet 😉 Morgen, geht's weiter 🙂

  • 0.7.14 released

    • 0.7.14: Update rockchip kernel to 4.4.167,
    • 0.7.14: Update mainline kernel to 5.0,

    Aktuell noch ungetestet.

  • 0.7.14 ist nicht empfehlenswert. (Bei mir zumindestens!!)

    Was geht?

    • WiFi

    Was nicht geht?

    • WiFi & PCIe NVMe SSD zusammen - crash!
    • PCIe NVMe SSD alleine - crash!

    Für mich ist der angebliche Fix, der irgendwie was drumherum bastelt, damit PCIe & WiFi zusammen funktioniert keine Lösung. Das macht jetzt aktuell mehr Probleme als vorher.

    Meine Idee wäre, zwei dts Files, einmal ist WiFi an, für Leute die es brauchen und einmal ist es aus. Hoffentlich findet jemand eine vernünftige Lösung!!

    Ich bleibe weiterhin bei 0.7.11 - absolut stabil, PCIe stabil, SATA läuft (mit der richtigen Karte), auf WiFi kann ich persönlich verzichten!

    Ich möchte hier aber erwähnen, das es wohl Leute gibt, bei denen das funktioniert.

  • Mal ein 0.7.14 Image eingeschmissen und Mainline angetestet. Und jetzt wird es verwirrend..

    Was geht?

    • PCIe (auch mit gestecktem WiFi-Modul)

    Was nicht geht?

    • WiFi
  • Hallo,

    mein Board ist nun angekommen und ich wollte mich per SSH drauf einloggen um PCIe SATA Karte zu aktivieren.
    Wie sind da die Standard Zugangsdaten?

    Gruß,
    Christoph

  • Ayufan Images nutzen

    user: rock64
    pw: rock64
    
  • ROCKPro64 - Debian 11 installieren

    ROCKPro64 bullseye debian rockpro64
    1
    0 Stimmen
    1 Beiträge
    497 Aufrufe
    Niemand hat geantwortet
  • ROCKPro64 - Debian Bullseye Teil 1

    ROCKPro64 debian linux rockpro64
    17
    4
    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.
  • OpenWrt

    Images rockpro64
    1
    0 Stimmen
    1 Beiträge
    214 Aufrufe
    Niemand hat geantwortet
  • ROCKPro64 - Das erste Mal

    Angeheftet Verschoben Hardware rockpro64
    5
    2
    1 Stimmen
    5 Beiträge
    969 Aufrufe
    FrankMF
    Ich kann heute die Fragen aller Fragen beantworten Damit ist leider die Frage immer noch unbeantwortet ob WLan und PCIe zusammen nutzbar ist!! Es geht!! Ich habe von MrFixit ein Testimage der RecalBox, benutzt das selbe Debian wie oben. Die Tage konnte man im IRC verfolgen, wie man dem Grundproblem näher kam und wohl einen Fix gebastelt hat, damit beides zusammen funktioniert. Mr.Fixit hat das in RecalBox eingebaut und ich durfte testen. # ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1 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: <NO-CARRIER,BROADCAST,MULTICAST,UP8000> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 62:03:b0:d6:dc:b3 brd ff:ff:ff:ff:ff:ff 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP8000> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether ac:83:f3:e6:1f:b2 brd ff:ff:ff:ff:ff:ff inet 192.168.178.27/24 brd 192.168.178.255 scope global wlan0 valid_lft forever preferred_lft forever inet6 2a02:908:1262:4680:ae83:f3ff:fee6:1fb2/64 scope global dynamic valid_lft 7145sec preferred_lft 3545sec inet6 fe80::ae83:f3ff:fee6:1fb2/64 scope link valid_lft forever preferred_lft forever # ls /mnt bin etc media recalbox sd.img test2.img boot home mnt root selinux tmp crypthome lib opt run srv usr dev lost+found proc sbin sys var # fdisk BusyBox v1.27.2 (2019-02-01 22:43:19 EST) multi-call binary. Usage: fdisk [-ul] [-C CYLINDERS] [-H HEADS] [-S SECTORS] [-b SSZ] DISK Change partition table -u Start and End are in sectors (instead of cylinders) -l Show partition table for each DISK, then exit -b 2048 (for certain MO disks) use 2048-byte sectors -C CYLINDERS Set number of cylinders/heads/sectors -H HEADS Typically 255 -S SECTORS Typically 63 # fdisk -l Disk /dev/mmcblk0: 15 GB, 15931539456 bytes, 31116288 sectors 486192 cylinders, 4 heads, 16 sectors/track Units: cylinders of 64 * 512 = 32768 bytes Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type /dev/mmcblk0p1 * 2,10,9 10,50,40 32768 163839 131072 64.0M c Win95 FAT32 (LBA) Partition 1 does not end on cylinder boundary /dev/mmcblk0p2 * 16,81,2 277,102,17 262144 4456447 4194304 2048M 83 Linux Partition 2 does not end on cylinder boundary /dev/mmcblk0p3 277,102,18 1023,254,63 4456448 31115263 26658816 12.7G 83 Linux Partition 3 does not end on cylinder boundary Disk /dev/nvme0n1: 233 GB, 250059350016 bytes, 488397168 sectors 2543735 cylinders, 12 heads, 16 sectors/track Units: cylinders of 192 * 512 = 98304 bytes Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type /dev/nvme0n1p1 1,0,1 907,11,16 2048 488397167 488395120 232G 83 Linux # Oben sieht man eine funktionierende WLan-Verbindung, das LAN-Kabel war entfernt. Unten sieht man die PCIe NVMe SSD, gemountet nach /mnt und Inhaltsausgabe. Das sollte beweisen, das der Ansatz der Lösung funktioniert. Leider kann ich nicht sagen, das es zum jetzigen Zeitpunkt stabil läuft. Ich habe einfach so Reboots, kann den Fehler aktuell aber nicht fangen. Mal sehen ob ich noch was finde. Aber, es ist ein Anfang!
  • ROCKPro64 - Armbian nand-sata-install

    Verschoben Armbian armbian rockpro64
    14
    6
    0 Stimmen
    14 Beiträge
    2k Aufrufe
    FrankMF
    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.
  • Kernel updaten NVMe / SDCard

    Verschoben ROCKPro64 rockpro64
    1
    1
    0 Stimmen
    1 Beiträge
    914 Aufrufe
    Niemand hat geantwortet
  • NAS Gehäuse für den ROCKPro64

    Verschoben Hardware rockpro64
    4
    0 Stimmen
    4 Beiträge
    2k Aufrufe
    FrankMF
    POWER-LED Die LEDs werden mit 3,3 Volt versorgt. Das ist jetzt recht einfach POWER LED + / Pi2-Connector Pin 1 (3,3V) POWER-LED - / Pi2-Connector Pin 9 (GND) Pi2-Connector [image: 1537358093301-img_20180919_134656_ergebnis-resized.jpg] [image: 1537358113804-img_20180919_134731_ergebnis.jpg]
  • SPI funktioniert

    ROCKPro64 rockpro64
    4
    0 Stimmen
    4 Beiträge
    958 Aufrufe
    FrankMF
    Wie ich jetzt mehrmals festgestellt habe, ist das System von der USB3 Platte instabil. [111985.654653] EXT4-fs error (d4: inode #16354: comm systemd: r[111985.837719] EXT4-fs error Das killt dann das komplette System. Ob das an meiner Hardware liegt, weiß ich nicht. Also, wer da draußen so ein System einsetzen will, Vorsicht! Die USB3-Schnittstelle scheint noch einige Bugs zu haben!! Mein NVMe System dagegen ist absolut stabil!