linux-nerds.org

Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.

Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).

Kernel updaten NVMe / SDCard

Verschoben ROCKPro64

1 Beiträge 1 Kommentatoren 912 Aufrufe

FrankM

schrieb am

Wir müssen uns nochmal was mit dem Kernelupdaten bei folgender Installation beschäftigen.

Installation

ROCKPro64
SD-Karte
PCIe-NVMe-Adapter mit SSD

Bei dieser Installation nutzen wir die SD-Karte nur zum Booten und binden so früh wie möglich das Rootverzeichnis (/) ein. Dieses Rootverzeichnis liegt auf der SSD.

Verzeichnis Struktur

 rock64@rockpro64v2_1_TEST:~$ df -h
 Filesystem      Size  Used Avail Use% Mounted on
 udev            992M     0  992M   0% /dev
 tmpfs           200M  448K  199M   1% /run
 /dev/nvme0n1    229G  8,5G  209G   4% /
 tmpfs           996M     0  996M   0% /dev/shm
 tmpfs           5,0M  4,0K  5,0M   1% /run/lock
 tmpfs           996M     0  996M   0% /sys/fs/cgroup
 /dev/mmcblk0p6  112M  4,0K  112M   1% /boot/efi
 tmpfs           200M     0  200M   0% /run/user/1000

Hier sieht man die Rootpartition /, die auf /dev/nvme0n1 verweist.
Und die Bootpartition /boot/efi, die auf /dev/mmcblk0p6 liegt.

SD-Karte

Device          Start       End   Sectors  Size Type
/dev/mmcblk0p1     64      8063      8000  3,9M Linux filesystem
/dev/mmcblk0p2   8064      8191       128   64K Linux filesystem
/dev/mmcblk0p3   8192     16383      8192    4M Linux filesystem
/dev/mmcblk0p4  16384     24575      8192    4M Linux filesystem
/dev/mmcblk0p5  24576     32767      8192    4M Linux filesystem
/dev/mmcblk0p6  32768    262143    229376  112M Microsoft basic data
/dev/mmcblk0p7 262144 124735454 124473311 59,4G Linux filesystem

SSD

rock64@rockpro64v2_1_TEST:~$ ls /
bin   boot_BAK  etc   lib         media  opt   root  sbin  sys  usr
boot  dev       home  lost+found  mnt    proc  run   srv   tmp  var

Was passiert jetzt, wenn man den Kernel updatet?

Ich mache das fast immer so, das ich mir vom Kamil alle Files runterlade und diese dann per

sudo dpkg -i *.deb

installiere. Dabei werden die neuen Files in /boot reingeschrieben.

rock64@rockpro64v2_1_TEST:~$ ls /boot
config-4.4.132-1075-rockchip-ayufan-ga83beded8524
config-4.4.154-1122-rockchip-ayufan-g7859b9b904a9
config-4.4.154-1124-rockchip-ayufan-ged3ce4d15ec1
dtbs
efi
extlinux
filesystem.packages
filesystem.packages-remove
initrd.img-4.4.132-1075-rockchip-ayufan-ga83beded8524
initrd.img-4.4.154-1122-rockchip-ayufan-g7859b9b904a9
initrd.img-4.4.154-1124-rockchip-ayufan-ged3ce4d15ec1
System.map-4.4.132-1075-rockchip-ayufan-ga83beded8524
System.map-4.4.154-1122-rockchip-ayufan-g7859b9b904a9
System.map-4.4.154-1124-rockchip-ayufan-ged3ce4d15ec1
vmlinuz-4.4.132-1075-rockchip-ayufan-ga83beded8524
vmlinuz-4.4.154-1122-rockchip-ayufan-g7859b9b904a9
vmlinuz-4.4.154-1124-rockchip-ayufan-ged3ce4d15ec1

Wir sehen hier, das es dort drei verschiedene Kernel gibt.

4.4.132-1075
4.4.154-1122
4.4.154-1124

Jetzt installieren wir mal einen Mainline Kernel.
Dazu laden wir die drei benötigten Files herunter.

Dann ein

sudo dpkg -i *.deb

Ausgabe

 rock64@rockpro64v2_1_TEST:~$ sudo dpkg -i *.deb
 Vormals nicht ausgewähltes Paket linux-headers-4.19.0-1073-ayufan-ga6e013135a6e wird gewählt.
 (Lese Datenbank ... 101525 Dateien und Verzeichnisse sind derzeit installiert.)
 Vorbereitung zum Entpacken von linux-headers-4.19.0-1073-ayufan-ga6e013135a6e_4.19.0-1073-ayufan_arm64.deb ...
 Entpacken von linux-headers-4.19.0-1073-ayufan-ga6e013135a6e (4.19.0-1073-ayufan) ...
 Vormals nicht ausgewähltes Paket linux-image-4.19.0-1073-ayufan-ga6e013135a6e wird gewählt.
 Vorbereitung zum Entpacken von linux-image-4.19.0-1073-ayufan-ga6e013135a6e_4.19.0-1073-ayufan_arm64.deb ...
 Entpacken von linux-image-4.19.0-1073-ayufan-ga6e013135a6e (4.19.0-1073-ayufan) ...
 Vormals nicht ausgewähltes Paket linux-image-4.19.0-1073-ayufan-ga6e013135a6e-dbg wird gewählt.
 Vorbereitung zum Entpacken von linux-image-4.19.0-1073-ayufan-ga6e013135a6e-dbg_4.19.0-1073-ayufan_arm64.deb ...
 Entpacken von linux-image-4.19.0-1073-ayufan-ga6e013135a6e-dbg (4.19.0-1073-ayufan) ...
 linux-headers-4.19.0-1073-ayufan-ga6e013135a6e (4.19.0-1073-ayufan) wird eingerichtet ...
 linux-image-4.19.0-1073-ayufan-ga6e013135a6e (4.19.0-1073-ayufan) wird eingerichtet ...
 update-initramfs: Generating /boot/initrd.img-4.19.0-1073-ayufan-ga6e013135a6e
 Creating new extlinux.conf...
 Installing new extlinux.conf...
 linux-image-4.19.0-1073-ayufan-ga6e013135a6e-dbg (4.19.0-1073-ayufan) wird eingerichtet ...

Jetzt schauen wir uns das Verzeichnis von eben nochmal an.

rock64@rockpro64v2_1_TEST:~$ ls /boot
config-4.19.0-1073-ayufan-ga6e013135a6e
config-4.4.132-1075-rockchip-ayufan-ga83beded8524
config-4.4.154-1122-rockchip-ayufan-g7859b9b904a9
config-4.4.154-1124-rockchip-ayufan-ged3ce4d15ec1
dtbs
efi
extlinux
filesystem.packages
filesystem.packages-remove
initrd.img-4.19.0-1073-ayufan-ga6e013135a6e
initrd.img-4.4.132-1075-rockchip-ayufan-ga83beded8524
initrd.img-4.4.154-1122-rockchip-ayufan-g7859b9b904a9
initrd.img-4.4.154-1124-rockchip-ayufan-ged3ce4d15ec1
System.map-4.19.0-1073-ayufan-ga6e013135a6e
System.map-4.4.132-1075-rockchip-ayufan-ga83beded8524
System.map-4.4.154-1122-rockchip-ayufan-g7859b9b904a9
System.map-4.4.154-1124-rockchip-ayufan-ged3ce4d15ec1
vmlinuz-4.19.0-1073-ayufan-ga6e013135a6e
vmlinuz-4.4.132-1075-rockchip-ayufan-ga83beded8524
vmlinuz-4.4.154-1122-rockchip-ayufan-g7859b9b904a9
vmlinuz-4.4.154-1124-rockchip-ayufan-ged3ce4d15ec1

Wir sehen den neuen Kernel 4.19 Aktuell läuft folgender Kernel.

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

Wir starten mal neu!

sudo reboot now

Aufpassen! Aktuell geht der Reboot mit Kernel 4.4. so nicht. Mal bitte die Reset Taste auf dem ROCKPro64 betätigen!

Wir schauen mal nach dem Kernel.

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

Hoppla, was das? Er startet immer noch den Kernel 4.4.154 Warum?

Bootvorgang

Beim Booten von der SD-Karte wird von dort der Kernel geladen, erst später schalten wir dann auf die SSD um. Damit ist die Aktualisierung von oben erst mal wirkungslos. Aber das ist recht einfach, wir müssen die Verzeichnisse nur identisch halten.

SD-Karte mounten

Nochmal auf die SD-Karte zurück gehen. Die Struktur von oben sieht so aus.

Device          Start       End   Sectors  Size Type
/dev/mmcblk0p1     64      8063      8000  3,9M Linux filesystem
/dev/mmcblk0p2   8064      8191       128   64K Linux filesystem
/dev/mmcblk0p3   8192     16383      8192    4M Linux filesystem
/dev/mmcblk0p4  16384     24575      8192    4M Linux filesystem
/dev/mmcblk0p5  24576     32767      8192    4M Linux filesystem
/dev/mmcblk0p6  32768    262143    229376  112M Microsoft basic data

Die Partition

/dev/mmcblk0p6  112M  4,0K  112M   1% /boot/efi

ist schon gemountet. Die interessiert aber nicht. Wir brauchen das Rootverzeichnis der SD-Karte. Das ist die Partition

/dev/mmcblk0p7

Das Mounten wir jetzt mal eben nach /mnt

 sudo mount /dev/mmcblk0p7 /mnt

Dort interessiert uns das Verzeichnis boot

rock64@rockpro64v2_1_TEST:~$ ls /mnt/boot
config-4.4.132-1075-rockchip-ayufan-ga83beded8524
config-4.4.154-1122-rockchip-ayufan-g7859b9b904a9
config-4.4.154-1124-rockchip-ayufan-ged3ce4d15ec1
dtbs
efi
extlinux
filesystem.packages
filesystem.packages-remove
initrd.img-4.4.132-1075-rockchip-ayufan-ga83beded8524
initrd.img-4.4.154-1122-rockchip-ayufan-g7859b9b904a9
initrd.img-4.4.154-1124-rockchip-ayufan-ged3ce4d15ec1
System.map-4.4.132-1075-rockchip-ayufan-ga83beded8524
System.map-4.4.154-1122-rockchip-ayufan-g7859b9b904a9
System.map-4.4.154-1124-rockchip-ayufan-ged3ce4d15ec1
vmlinuz-4.4.132-1075-rockchip-ayufan-ga83beded8524
vmlinuz-4.4.154-1122-rockchip-ayufan-g7859b9b904a9
vmlinuz-4.4.154-1124-rockchip-ayufan-ged3ce4d15ec1

Wer bis hierhin mitgekommen ist, weiß jetzt wo das Problem liegt Auf der SD-Karte muss ebenfalls der Mainline Kernel drauf. Also kopieren wir uns das mal eben rüber.

Quelle

rock64@rockpro64v2_1_TEST:~$ ls /boot
config-4.19.0-1073-ayufan-ga6e013135a6e
config-4.4.132-1075-rockchip-ayufan-ga83beded8524
config-4.4.154-1122-rockchip-ayufan-g7859b9b904a9
config-4.4.154-1124-rockchip-ayufan-ged3ce4d15ec1
dtbs
efi
extlinux
filesystem.packages
filesystem.packages-remove
initrd.img-4.19.0-1073-ayufan-ga6e013135a6e
initrd.img-4.4.132-1075-rockchip-ayufan-ga83beded8524
initrd.img-4.4.154-1122-rockchip-ayufan-g7859b9b904a9
initrd.img-4.4.154-1124-rockchip-ayufan-ged3ce4d15ec1
System.map-4.19.0-1073-ayufan-ga6e013135a6e
System.map-4.4.132-1075-rockchip-ayufan-ga83beded8524
System.map-4.4.154-1122-rockchip-ayufan-g7859b9b904a9
System.map-4.4.154-1124-rockchip-ayufan-ged3ce4d15ec1
vmlinuz-4.19.0-1073-ayufan-ga6e013135a6e
vmlinuz-4.4.132-1075-rockchip-ayufan-ga83beded8524
vmlinuz-4.4.154-1122-rockchip-ayufan-g7859b9b904a9
vmlinuz-4.4.154-1124-rockchip-ayufan-ged3ce4d15ec1

Ziel

rock64@rockpro64v2_1_TEST:~$ ls /mnt/boot
config-4.4.132-1075-rockchip-ayufan-ga83beded8524
config-4.4.154-1122-rockchip-ayufan-g7859b9b904a9
config-4.4.154-1124-rockchip-ayufan-ged3ce4d15ec1
dtbs
efi
extlinux
filesystem.packages
filesystem.packages-remove
initrd.img-4.4.132-1075-rockchip-ayufan-ga83beded8524
initrd.img-4.4.154-1122-rockchip-ayufan-g7859b9b904a9
initrd.img-4.4.154-1124-rockchip-ayufan-ged3ce4d15ec1
System.map-4.4.132-1075-rockchip-ayufan-ga83beded8524
System.map-4.4.154-1122-rockchip-ayufan-g7859b9b904a9
System.map-4.4.154-1124-rockchip-ayufan-ged3ce4d15ec1
vmlinuz-4.4.132-1075-rockchip-ayufan-ga83beded8524
vmlinuz-4.4.154-1122-rockchip-ayufan-g7859b9b904a9
vmlinuz-4.4.154-1124-rockchip-ayufan-ged3ce4d15ec1

Kopieren

sudo cp -r /boot/* /mnt/boot

Kontrolle Ziel

rock64@rockpro64v2_1_TEST:~$ ls /mnt/boot
config-4.19.0-1073-ayufan-ga6e013135a6e
config-4.4.132-1075-rockchip-ayufan-ga83beded8524
config-4.4.154-1122-rockchip-ayufan-g7859b9b904a9
config-4.4.154-1124-rockchip-ayufan-ged3ce4d15ec1
dtbs
efi
extlinux
filesystem.packages
filesystem.packages-remove
initrd.img-4.19.0-1073-ayufan-ga6e013135a6e
initrd.img-4.4.132-1075-rockchip-ayufan-ga83beded8524
initrd.img-4.4.154-1122-rockchip-ayufan-g7859b9b904a9
initrd.img-4.4.154-1124-rockchip-ayufan-ged3ce4d15ec1
System.map-4.19.0-1073-ayufan-ga6e013135a6e
System.map-4.4.132-1075-rockchip-ayufan-ga83beded8524
System.map-4.4.154-1122-rockchip-ayufan-g7859b9b904a9
System.map-4.4.154-1124-rockchip-ayufan-ged3ce4d15ec1
test
vmlinuz-4.19.0-1073-ayufan-ga6e013135a6e
vmlinuz-4.4.132-1075-rockchip-ayufan-ga83beded8524
vmlinuz-4.4.154-1122-rockchip-ayufan-g7859b9b904a9
vmlinuz-4.4.154-1124-rockchip-ayufan-ged3ce4d15ec1

Da ist der Kernel 4.19. Noch was Wichtiges, wir müssen die extlinux.conf wieder anpassen.

sudo nano /mnt/boot/extlinux/extlinux.conf

Ich setze voraus, das das bekannt ist. Ansonsten hier zum Nachlesen!

Wir entfernen den Mount.

sudo umount /mnt
sudo reboot now

Erinnerung! Reboot now ist in Kernel 4.4. aktuell kaputt

Und nachschauen!

rock64@rockpro64v2_1_TEST:~$ uname -a
Linux rockpro64v2_1_TEST 4.19.0-1073-ayufan-ga6e013135a6e #1 SMP PREEMPT Tue Oct 23 09:19:54 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux

Yeah! Kernel 4.19 läuft. Ich hoffe das Prinzip ist verständlich und ihr könnt das gut nachbauen. Wir wollen mal hoffen, das wir in Zukunft einen u-boot sehen, der in der Lage ist direkt von der PCIe-NVMe-Karte zu booten. Das würde einiges vereinfachen, den u-boot in den SPI Flash und fertig! Ob es das mal gibt, weiß ich nicht. Im Moment müssen wir uns so behelfen. Da man den Kernel im Normalfall ja nicht jeden Tag aktualisiert, ist das eine praktikable Lösung!

Viel Spaß mit einem flotten ROCKPro64!

Anmelden zum Antworten

F

RockPro64 - Mainline Kernel 6.13.0-1197-ayufan
Beobachtet Ignoriert Geplant Angeheftet Gesperrt Verschoben ROCKPro64 rockpro64 linux
1

0 Stimmen

1 Beiträge

56 Aufrufe

Niemand hat geantwortet
F

ROCKPro64 - Das erste Mal
Beobachtet Ignoriert Geplant Angeheftet Gesperrt Verschoben Hardware rockpro64
5

2

1 Stimmen

5 Beiträge

960 Aufrufe

F

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!
F

USB-Adapter für eMMC-Modul
Beobachtet Ignoriert Geplant Angeheftet Gesperrt Verschoben Hardware hardware rockpro64
1

2

0 Stimmen

1 Beiträge

1k Aufrufe

Niemand hat geantwortet
F

SATA Karte Marvell 88SE9230 Chipsatz
Beobachtet Ignoriert Geplant Angeheftet Gesperrt Verschoben Hardware hardware rockpro64
19

0 Stimmen

19 Beiträge

6k Aufrufe

F

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
F

USB 3.0 - SATA Adapter
Beobachtet Ignoriert Geplant Angeheftet Gesperrt Verschoben Hardware hardware rockpro64
2

3

0 Stimmen

2 Beiträge

815 Aufrufe

F

Heute das Ganze mal mit einer Samsung 860 Pro mit 256GB. Eingesetztes Filesystem ext4 rock64@rockpro64v2_1:/mnt$ uname -a Linux rockpro64v2_1 4.4.132-1077-rockchip-ayufan-gbaf35a9343cb #1 SMP Mon Jul 30 14:06:57 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux Speedtest rock64@rockpro64v2_1:/mnt$ sudo iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Iozone: Performance Test of File I/O Version $Revision: 3.429 $ Compiled for 64 bit mode. Build: linux Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins Al Slater, Scott Rhine, Mike Wisner, Ken Goss Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR, Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner, Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone, Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root, Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer, Vangel Bojaxhi, Ben England, Vikentsi Lapa. Run began: Tue Jul 31 14:27:17 2018 Include fsync in write timing O_DIRECT feature enabled Auto Mode File size set to 102400 kB Record Size 4 kB Record Size 16 kB Record Size 512 kB Record Size 1024 kB Record Size 16384 kB Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 17896 23350 30390 31362 21611 14611 102400 16 56756 59180 86296 93819 51778 57327 102400 512 201347 221961 220840 222338 210887 230781 102400 1024 253752 273695 263884 266256 250153 273528 102400 16384 351112 356007 366417 372264 368721 356177 iozone test complete. DD Schreiben rock64@rockpro64v2_1:/mnt$ 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, 12.8358 s, 335 MB/s Lesen rock64@rockpro64v2_1:/mnt$ sudo dd if=sd.img of=/dev/null bs=1M count=4096 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 11.4787 s, 374 MB/s Fazit Damit scheint der Adapter ganz gut am USB3.0 zu funktionieren. Die Schreibgeschwindigkeit ist ca. dreimal höher als mit der anderen SSD.
F

Benchmark Script
Beobachtet Ignoriert Geplant Angeheftet Gesperrt Verschoben ROCKPro64 rockpro64
2

0 Stimmen

2 Beiträge

652 Aufrufe

F

Mainline Mein gekürztes Ergebnis auf einem ROCKPro64 v2.0 mit 4GB RAM und 4.18er Kernel, dieser ROCK benutzt eine SD-Karte! Gekürzt Distributor ID: Ubuntu Description: Ubuntu 18.04.1 LTS Release: 18.04 Codename: bionic Architecture: arm64 Uptime: 16:14:56 up 4 min, 1 user, load average: 0.08, 0.02, 0.01 Linux 4.18.0-rc5-1048-ayufan-g69e417fe38cf (rockpro64) 07/27/18 _aarch64_ (6 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 0.54 0.00 0.74 0.39 0.00 98.33 Device tps kB_read/s kB_wrtn/s kB_read kB_wrtn mmcblk0 20.63 634.58 48.26 168380 12804 nvme0n1 0.14 4.01 0.00 1064 0 total used free shared buff/cache available Mem: 3.8G 241M 3.4G 19M 201M 3.5G Swap: 0B 0B 0B ########################################################################## Komplett -> http://ix.io/1ix7
F

Vorserienmodell
Beobachtet Ignoriert Geplant Angeheftet Gesperrt Verschoben ROCKPro64 rockpro64
1

0 Stimmen

1 Beiträge

558 Aufrufe

Niemand hat geantwortet
F

ROCKPro64 Forum
Beobachtet Ignoriert Geplant Angeheftet Gesperrt Verschoben ROCKPro64 rockpro64
1

1

0 Stimmen

1 Beiträge

683 Aufrufe

Niemand hat geantwortet