Hallo zusammen,
ich habe mir vor ein paar Tagen ein RockPro64 (mit Serverzubehör) gekauft und wollte Debian drauf installieren.
Ich habe zur Erstellung des Installationsimage das partition.img vom 1.7.2020 (?) und da firmware.rockpro64-rk3399.img vom 4.8.2020 zusammengepackt und auf eine SD Karte geschrieben.
Das System bootet auch sauber das sehe ich sowohl auf der seriellen Schnittstelle als auch auf dem HDMI.
Auf beiden kommt folgende Ausgabe:
*U-Boot TPL 2020.07+dfsg-1 (Jul 08 2020 - 23:29:02)
Channel 0: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
Channel 1: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
256B stride
256B stride
lpddr4_set_rate: change freq to 400000000 mhz 0, 1
lpddr4_set_rate: change freq to 800000000 mhz 1, 0
Trying to boot from BOOTROM
Returning to boot ROM...
U-Boot SPL 2020.07+dfsg-1 (Jul 08 2020 - 23:29:02 +0000)
Trying to boot from MMC1
U-Boot 2020.07+dfsg-1 (Jul 08 2020 - 23:29:02 +0000)
SoC: Rockchip rk3399
Reset cause: POR
Model: Pine64 RockPro64 v2.1
DRAM: 3.9 GiB
PMIC: RK808
MMC: mmc@fe310000: 2, mmc@fe320000: 1, sdhci@fe330000: 0
Loading Environment from SPI Flash... SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
*** Warning - bad CRC, using default environment
In: serial
Out: vidconsole
Err: vidconsole
Model: Pine64 RockPro64 v2.1
Net: eth0: ethernet@fe300000
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
144 bytes read in 9 ms (15.6 KiB/s)
1: Debian-Installer
Retrieving file: /initrd.gz
27584096 bytes read in 1565 ms (16.8 MiB/s)
Retrieving file: /vmlinuz
18759536 bytes read in 1070 ms (16.7 MiB/s)
Retrieving file: /dtbs/rockchip/rk3399-rockpro64.dtb
96363 bytes read in 26 ms (3.5 MiB/s)
## Flattened Device Tree blob at 01f00000
Booting using the fdt blob at 0x1f00000
Loading Ramdisk to f04cd000, end f1f1b660 ... OK
Loading Device Tree to 00000000f04b2000, end 00000000f04cc86a ... OK
Starting kernel ...*
Dann stoppt die Ausgabe auf dem HDMI.
Auf seriell kommt noch:
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[ 0.000000] Linux version 4.19.0-10-arm64 (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.132-1 (2020-07-24) 0.000000] Machine model: Pine64 RockPro64
[ 0.000000] eaycon: uart8250 at MMIO32 0x00000000ff1a0000 (options '')
[ 0.000000] bootconsole [uart8250] enabled
[ 0.000000] efi: Getting EFI parameters from FDT:
[ 0.000000] efi: UEFI not found.
[ 0.000000] cma: Reserved 64 MiB at 0x00000000f4000000
[ 0.000000] NUMA: No NUMA configuration found
[ 0.000000] NUMA: Faking a node at [mem 0x0000000000200000-0x00000000f7ffffff]
[ 0.000000] NUMA: NODE_DATA [mem 0xf3f8a3c0-0xf3f8bb7f]
[ 0.000000] Zone ranges:
[ 0.000000] DMA32 [mem 0x0000000000200000-0x00000000f7ffffff]
[ 0.000000] Normal empty
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000200000-0x00000000f7ffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000200000-0x00000000f7ffffff]
[ 0.000000] psci: probing for conduit method from DT.
[ 0.000000] psci: PSCIv1.1 detected in firmware.
[ 0.000000] psci: Using standard PSCI v0.2 function IDs
[ 0.000000] psci: MIGRATE_INFO_TYPE not supported.
[ 0.000000] psci: SMC Calling Convention v1.0
[ 0.000000] random: get_random_bytes called from start_kernel+0x9c/0x4c0 with crng_init=0
[ 0.000000] percpu: Embedded 25 pages/cpu s61976 r8192 d32232 u102400
[ 0.000000] Detected VIPT I-cache on CPU0
[ 0.000000] CPU features: enabling workaround for ARM erratum 845719
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 999432
[ 0.000000] Policy zone: DMA32
[ 0.000000] Kernel command line: earlycon=uart8250,mmio32,0xff1a0000 swiotlb=1
[ 0.000000] Memory: 3881760K/4061184K available (8892K kernel code, 1614K rwdata, 2812K rodata, 4928K init, 529K bss, 113888K reserved, 65536K cma-reserved)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1
[ 0.000000] ftrace: allocating 33247 entries in 1 pages
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=6.
[ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=6
[ 0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[ 0.000000] GICv3: GIC: Using split EOI/Deactivate mode
[ 0.000000] GICv3: Distributor has no Range Selector support
[ 0.000000] GICv3: no VLPI support, no direct LPI support
[ 0.000000] ITS [mem 0xfee20000-0xfee3ffff]
[ 0.000000] ITS@0x00000000fee20000: allocated 65536 Devices @f3980000 (flat, esz 8, psz 64K, shr 0)
[ 0.000000] ITS: using cache flushing for cmd queue
[ 0.000000] GIC: using LPI property table @0x00000000f3940000
[ 0.000000] GICv3: CPU0: found redistributor 0 region 0:0x00000000fef00000
[ 0.000000] CPU0: using LPI pending table @0x00000000f3950000
[ 0.000000] GIC: using cache flushing for LPI property table
[ 0.000000] GICv3: GIC: PPI partition interrupt-partition-0[0] { /cpus/cpu@0[0] /cpus/cpu@1[1] /cpus/cpu@2[2] /cpus/cpu@3[3] }[ 0.000000] GICv3: GIC: PPI partition interrupt-partition-1[1] { /cpus/cpu@100[4] /cpus/cpu@101[5] }
[ 0.000000] clk: couldn't get clock 5 for /clock-controller@ff760000
[ 0.000000] rockchip_clk_of_add_provider: could not register clk provider
[ 0.000000] arch_timer: cp15 timer(s) unning at 24.00MHz (phys).
[ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns
[ 0.000007] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns
[ 0.001638] Failed to get pclk for 'rk_timer'
[ 0.002079] Failed to initialize '/rktimer@ff850000': -517
[ 0.004095] Console: colour dummy device 80x25
[ 0.004536] console [tty0] enabled
[ 0.004880] bootconsole [uart8250] disabled
Danach kommt auf der seriellen Schnittstelle auch nichts mehr 
Das Board ist so wie geliefert, ich habe also noch nichts geändert (SPI, ..).
Was muß ich noch beachten?
Vielen Dank und viele Grüße
gabs5807
Kannst Du einfach mal bitte eben das Image vom Kamil testen?
Ein Debian Buster Minimal.
Dein Problem muss ich mir mal ansehen und testen, ich hatte hier mit den Debian Images nicht so wirklich viele Probleme. Wobei, wenn ich nachdenke. ich nicht den u-boot von Debian nutze. Mein u-boot ist im SPI. Ok, lass mich das mal testen.
Im Fediverse -> @FrankM@nrw.social
Mensch, haben die bei Debian wieder was geändert!?
Gut, ich habe dieses File heruntergeladen, Download-Ordner -> https://d-i.debian.org/daily-images/arm64/daily/u-boot/
Dann das File-> https://d-i.debian.org/daily-images/arm64/daily/u-boot/rockpro64-rk3399.img.gz
Ab auf eine SD-Karte und starten.
Da jetzt der u-boot 2020-07 benutzt wird, müsste ich eigentlich sofort testen. Bin doch so furchtbar neugierig Und deswegen vielen Dank für den wichtigen Hinweis, das sich da was getan hat.
Wenn es weiter bei Dir klemmt, einfach fragen 
Im Fediverse -> @FrankM@nrw.social
@gabs5807 lass der kiste vielleicht ein paar minuten mehr zeit
hatte ich auch schon, dann irgendwann einmal vergessen das sie noch an war und nach 5min war sie dann da
@FrankM sagte in bootconsole [uart8250] disabled:
Kannst Du einfach mal bitte eben das Image vom Kamil testen?
Ein Debian Buster Minimal.
Dein Problem muss ich mir mal ansehen und testen, ich hatte hier mit den Debian Images nicht so wirklich viele Probleme. Wobei, wenn ich nachdenke. ich nicht den u-boot von Debian nutze. Mein u-boot ist im SPI. Ok, lass mich das mal testen.
Hallo FrankM, ich habe mir schon mal das Mrfixit2001 img auf SD Card geschrieben. das Startet ohne Probleme. Ist aber halt kein installer.
Es wird auch das emmc und die zwei Festplatten erkannt, die ich im Server drinnen habe.
Also sollte die hardware ok sein ... .
@FrankM sagte in bootconsole [uart8250] disabled:
Mensch, haben die bei Debian wieder was geändert!?
Gut, ich habe dieses File heruntergeladen, Download-Ordner -> https://d-i.debian.org/daily-images/arm64/daily/u-boot/
Dann das File-> https://d-i.debian.org/daily-images/arm64/daily/u-boot/rockpro64-rk3399.img.gz
Ab auf eine SD-Karte und starten.
- mit Kamils u-boot im SPI lud der Kernel nicht.
- SPI deaktiviert
- mit Debians u-boot startet der Installer!
- eine Ausgabe erfolgt auf der seriellen Konsole & HDMI
- es kommt die Abfrage nach der Installationssprache
Da jetzt der u-boot 2020-07 benutzt wird, müsste ich eigentlich sofort testen. Bin doch so furchtbar neugierig
Wenn es weiter bei Dir klemmt, einfach fragen
Ich habe meine SD nach dem Readme erstellt, das ich hier gefunden habe:
Der weiterführende link der auf die img zeigen soll stimmen zwar nicht mehr, aber ich habe sie hier gefunden:
partition.img.gz
rockpro64-rk3399.img.gz
Brauche ich das partition.img.gz nicht mehr, da Du nur das rockpro64-rk3399.img.gz auf die SD-Karte schreibst?
Das System sollte eigentlich auf die eMMC, der Cloud Content (Next Cloud) auf eine Festplatte.
Booten von eMMC sollte auch ohne SPI flashen gehen oder?
@kosmonaut-pirx sagte in bootconsole [uart8250] disabled:
@gabs5807 lass der kiste vielleicht ein paar minuten mehr zeit
hatte ich auch schon, dann irgendwann einmal vergessen das sie noch an war und nach 5min war sie dann da
Hallo kosmonaut-pirx, das werde ich gleich morgen mal probieren 
- ist ja die leichteste Übung 
. Mich haben nur die letzten zwei Zeilen gewundert
...
[ 0.004536] console [tty0] enabled
[ 0.004880] bootconsole [uart8250] disabled
Kam die Ausgabe bei dir dann auf HDMI oder seriell?
@gabs5807 weiß nicht mehr, glaub hdmi
@FrankM Hallo FrankM, ich habe es jetzt so gemacht wie Du es beschrieben hast. Leider mit dem gleichen Ergebniss - das System hängt nach der Ausgabe 'bootconsole [uart8250] disabled'.
Da ich gesehen habe, dass es hier eine Datei 'rk3399-rockpro64.dtb' und 'rk3399-rockpro64-v2.dtb' gibt, habe ich auf der SD Karte mal unter '/dtbs/rockchip/' die Datei 'rk3399-rockpro64.dtb' durch 'rk3399-rockpro64-v2.dtb' ersetzt (also auch umbenannt).
Jetzt bekomme ich auch den Installer .
Leider wird aber die Netzwerkkarte nicht erkannt :
[ (1*installer) 2 shell 3 shell 4- log ][ Jan 01 0:00 ]
lqqqqqqqqqqqqqqqqqqqqqu [!] Detect network hardware tqqqqqqqqqqqqqqqqqqqqqk
x x
x No Ethernet card was detected. If you know the name of the driver x
x needed by your Ethernet card, you can select it from the list. x
x x
x Driver needed by your Ethernet card: x
x x
x no ethernet card - x
x 3c59x: 3Com59x/3c9xx PCI Ethernet 0 x
x 8139cp: RealTek RTL-8139C+ series 10/100 PCI Ethernet a x
x 8139too: RealTek RTL-8139 Fast Ethernet a x
x 8390: Nationa Semiconductor 8390 Ethernet a x
x acenic: AceNIC/3C985/GA620 Gigabit Ethernet driver a x
x adm8211: Driver for IEEE 802.11b wireless cards based on ADMtek A a x
x alx: Qualcomm Atheros(R) AR816x/AR817x PCI-E Ethernet Network Dri a x
x amd-xgbe: AMD 10 Gigabit Ethernet Driver . x
x x
x <Go Back> x
x x
mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj
<Tab> moves; <Space> selects; <Enter> activates buttons
Sehr eigenartig 
...
Da die dtb Dateien ja binary(?) sind, kann ich da wohl nicht eingreifen, oder?
Eigentlich kann es doch nicht sein, dass die identisch HW (Board Revision V2.1) sich unterschiedlich verhält, oder?
@gabs5807 sagte in bootconsole [uart8250] disabled:
@FrankM sagte in bootconsole [uart8250] disabled:
Mensch, haben die bei Debian wieder was geändert!?
Gut, ich habe dieses File heruntergeladen, Download-Ordner -> https://d-i.debian.org/daily-images/arm64/daily/u-boot/
Dann das File-> https://d-i.debian.org/daily-images/arm64/daily/u-boot/rockpro64-rk3399.img.gz
Ab auf eine SD-Karte und starten.
- mit Kamils u-boot im SPI lud der Kernel nicht.
- SPI deaktiviert
- mit Debians u-boot startet der Installer!
- eine Ausgabe erfolgt auf der seriellen Konsole & HDMI
- es kommt die Abfrage nach der Installationssprache
Da jetzt der u-boot 2020-07 benutzt wird, müsste ich eigentlich sofort testen. Bin doch so furchtbar neugierig
Wenn es weiter bei Dir klemmt, einfach fragen
Ich habe meine SD nach dem Readme erstellt, das ich hier gefunden habe:
- Download firmware.rockpro64-rk3399.img.gz
- Download partition.img.gz
- zcat firmware.rockpro64-rk3399.img.gz partition.img.gz > complete_image.img
- dd if=complete_image.img of=your_chosen_boot_device bs=4M
Der weiterführende link der auf die img zeigen soll stimmen zwar nicht mehr, aber ich habe sie hier gefunden:
partition.img.gz
rockpro64-rk3399.img.gzBrauche ich das partition.img.gz nicht mehr, da Du nur das rockpro64-rk3399.img.gz auf die SD-Karte schreibst?
Das System sollte eigentlich auf die eMMC, der Cloud Content (Next Cloud) auf eine Festplatte.
Booten von eMMC sollte auch ohne SPI flashen gehen oder?
@FrankM
Habe gerade gesehen, dass der obengenannte Link auf die img Dateien wieder funktioniert 
und unter device-tree sind zwei rockpro64 dtb Dateien.
Die v2 ist anscheinend für die Board Revision 2.0 und die ohne 'v' für Board Revision v2.1 ...
@kosmonaut-pirx sagte in bootconsole [uart8250] disabled:
@gabs5807 weiß nicht mehr, glaub hdmi
Hat leider nicht funktioniert. Auch nach ca. fünfzehn Minuten kam nichts - werde HDMI noch seriell 
. Trotzdem vielen Dank für den Tip. Einen Versuch wars wert.
Erstmal gut, das der Link wieder geht. Die beiden Dateien heruntergeladen und das Image erzeugt. Das auf einen SD-Karte und den Debian Installer gestartet.
Die Ausgabe kommt auf HDMI und UART Schnittstelle.
Habe schnell den Installer über HDMI getestet, wie gehabt, aktuell nicht nutzbar.
Der Installer über UART läuft aktuell. Ich installiere gerade eine verschlüsselte Installation auf eine HDD an USB3. Ich bin gespannt
Danke für den Hinweis, das der Link wieder funktioniert!
Hallo zusammen, nach dem ich das img noch einmal neu erzeugt und auf die SD-Karte geschrieben habe geht jetzt soweit alles. Der installer startet und die Netzwerkkarte wird erkannt .
Ich komme allerdings erst morgen dazu, die Installation komplett durchzuführen. Ich melde mich dann wieder. Vielen Dank
Gerade für Dich nochmal getestet. Die verschlüsselte Installation auf eine HDD am USB3-Port geht einwandfrei. Zum Schluß die Daten noch kopieren und das Root-Device richtig eintragen.
Aber warum die Installation jetzt vom USB3-Port startet, weiß ich gerade auch nicht 
Hallo zusammen,
die Installation war erfolgreich und das debian läuft auf dem RockPro64 .
Es haben sich aber noch einige Fragen ergeben ...
Das System ist jetzt auf der eMMC Karte.
root@rp64:~# mount
...
/dev/mmcblk1p3 on / type ext4 (rw,relatime,errors=remount-ro)
...
/dev/mmcblk1p1 on /boot type ext2 (rw,relatime)
/dev/sdb1 on /srv type ext4 (rw,relatime)
Ursprünglich wollte ich '/boot' als vfat erzeugen, das lässt aber die Installation nicht zu .
Ich habe also ein ext2 daraus gemacht und haben dann auch gesehen, warum vfat nicht geht.
root@rp64:~# ls -l /boot
total 103128
-rw-r--r-- 1 root root 4850925 Jul 26 08:40 System.map-5.7.0-2-arm64
-rw-r--r-- 1 root root 241299 Jul 26 08:40 config-5.7.0-2-arm64
drwxr-xr-x 16 root root 4096 Aug 8 11:41 dtbs
drwxr-xr-x 2 root root 4096 Aug 8 18:54 extlinux
lrwxrwxrwx 1 root root 28086825 Aug 8 12:13 initrd.img -> initrd.img-5.7.0-2-arm64
-rw-r--r-- 1 root root 28086825 Aug 8 11:21 initrd.img-5.7.0-2-arm64
lrwxrwxrwx 1 root root 24 Aug 8 11:19 initrd.img.old -> initrd.img-5.7.0-2-arm64
drwx------ 2 root root 16384 Aug 8 11:14 lost+found
lrwxrwxrwx 1 root root 22079344 Aug 8 12:14 vmlinuz -> vmlinuz-5.7.0-2-arm64
-rw-r--r-- 1 root root 22079344 Jul 26 08:40 vmlinuz-5.7.0-2-arm64
lrwxrwxrwx 1 root root 21 Aug 8 11:19 vmlinuz.old -> vmlinuz-5.7.0-2-arm64
vfat kann keine symlinks.
Leider kann u-boot das anscheinend auch nicht, obwohl ich gesehen habe, dass es eigentlich ext filesysteme unterstützen sollte(?).
Ich habe das dann geändert, die symlinks gelöscht und die Dateien kopiert.
Jetzt ist mir der beschriebene 'workaround' zum erzeugen der extlinux.conf auch klar .
Würden symlinks funktionieren, müsste man die Datei nicht ändern, da der symlink immer auf die aktuelle initrd und den aktuellen vmlinuz zeigen würde.
Die Verzeichnisse dtbs und extlinux habe ich von dem Installationsmedium kopiert und die Datei extlinux.conf angepasst.
Mir war auch nicht klar, dass der u-boot mit auf der SD-Karte steht, oder ich ihn in den SPI schreiben muss (was ich noch nicht getan habe). Denn als ich die SD-Karte raus genommen haben tat das System keinen Mucks mehr ...
Hier stellt sich mir folgende Frage. Wie man mit fdisk sieht, beginnt die erste Partition auf der SD-Karte erst ab Block 32768, also nach 16k (siehe unten).
root@rp64:~# fdisk -l
Disk /dev/mmcblk0: 7.41 GiB, 7960788992 bytes, 15548416 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x847e49e7
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 * 32768 1953119 1920352 937.7M c W95 FAT32 (LBA)
Disk /dev/mmcblk1: 29.12 GiB, 31268536320 bytes, 61071360 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x668c199f
Device Boot Start End Sectors Size Id Type
/dev/mmcblk1p1 * 2048 16779263 16777216 8G 83 Linux
/dev/mmcblk1p2 16779264 33556479 16777216 8G 82 Linux swap / Solaris
/dev/mmcblk1p3 33556480 61071359 27514880 13.1G 83 Linux
Ist in den ersten 16k der u-boot?
Und kann ich den u-boot, wenn ich die 16k auf der eMMC frei mache (also mmcblk1p1 'boot' verkleinere) mit dd da drauf kopieren und bootet dann das System von der eMMC ohne SD-Karte?
Oder brauche ich den SPI dazu?
Bei der Installation habe ich auch noch festgestellt, dass eine SSD Festplatte, die sonst überall läuft Probleme macht.
Ich glaube, so etwas schon mal irgendwo gelesen zu haben.
Ich habe folgende Konstellation in meinem System:
root@rp64:~# lspci
00:00.0 PCI bridge: Fuzhou Rockchip Electronics Co., Ltd RK3399 PCI Express Root Port
01:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 01)
root@rp64:~# fdisk -l
...
Disk /dev/sda: 232.89 GiB, 250059350016 bytes, 488397168 sectors
Disk model: Samsung SSD 840
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5c2c6bdf
Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 488396799 488394752 232.9G 83 Linux
Disk /dev/sdb: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: SAMSUNG HD204UI
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xb3fad173
Device Boot Start End Sectors Size Id Type
/dev/sdb1 2048 3907028991 3907026944 1.8T 83 Linux
Der SATA Controller sollte kein Problem sein, der kommt auch von pine und ich habe festgestellt, dass das Problem beim Tauschen der Ports mit wandert.
Die SSD Samsunf SSD 840 EVO 'Disk model: Samsung SSD 840' (sda) funktioniert nicht richtig und meldet auch einige Fehler beim Zugriff (fdisk, mount, ...), der dann auch nicht funktioniert:
root@rp64:~# journalctl -xa
-- Logs begin at Mon 2020-08-03 09:46:28 CEST, end at Sat 2020-08-08 22:17:01 CEST. --
...
Aug 08 19:56:23 rp64 kernel: ata1.00: exception Emask 0x10 SAct 0x1 SErr 0x400000 action 0x6 frozen
Aug 08 19:56:23 rp64 kernel: ata1.00: irq_stat 0x08000000, interface fatal error
Aug 08 19:56:23 rp64 kernel: ata1: SError: { Handshk }
Aug 08 19:56:23 rp64 kernel: ata1.00: failed command: WRITE FPDMA QUEUED
Aug 08 19:56:23 rp64 kernel: ata1.00: cmd 61/08:00:00:08:00/00:00:00:00:00/40 tag 0 ncq dma 4096 out
res 40/00:00:00:08:00/00:00:00:00:00/40 Emask 0x10 (ATA bus error)
Aug 08 19:56:23 rp64 kernel: ata1.00: status: { DRDY }
Aug 08 19:56:23 rp64 kernel: ata1: hard resetting link
Aug 08 19:56:23 rp64 kernel: ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Aug 08 19:56:23 rp64 kernel: ata1.00: NCQ Send/Recv Log not supported
Aug 08 19:56:23 rp64 kernel: ata1.00: NCQ Send/Recv Log not supported
Aug 08 19:56:23 rp64 kernel: ata1.00: configured for UDMA/133
Aug 08 19:56:23 rp64 kernel: ata1: EH complete
Aug 08 19:56:23 rp64 kernel: EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
Aug 08 19:56:24 rp64 kernel: ata1.00: exception Emask 0x10 SAct 0x4 SErr 0x400000 action 0x6 frozen
Aug 08 19:56:24 rp64 kernel: ata1.00: irq_stat 0x08000000, interface fatal error
Aug 08 19:56:24 rp64 kernel: ata1: SError: { Handshk }
Aug 08 19:56:24 rp64 kernel: ata1.00: failed command: WRITE FPDMA QUEUED
Aug 08 19:56:24 rp64 kernel: ata1.00: cmd 61/40:10:00:39:40/05:00:01:00:00/40 tag 2 ncq dma 688128 out
res 40/00:10:00:39:40/00:00:01:00:00/40 Emask 0x10 (ATA bus error)
Aug 08 19:56:24 rp64 kernel: ata1.00: status: { DRDY }
Aug 08 19:56:24 rp64 kernel: ata1: hard resetting link
Aug 08 19:56:28 rp64 systemd[1]: systemd-fsckd.service: Succeeded.
Aug 08 19:56:34 rp64 kernel: ata1: softreset failed (1st FIS failed)
Aug 08 19:56:34 rp64 kernel: ata1: hard resetting link
Aug 08 19:56:44 rp64 kernel: ata1: softreset failed (1st FIS failed)
Aug 08 19:56:44 rp64 kernel: ata1: hard resetting link
Aug 08 19:57:19 rp64 kernel: ata1: softreset failed (1st FIS failed)
Aug 08 19:57:19 rp64 kernel: ata1: limiting SATA link speed to 3.0 Gbps
Aug 08 19:57:19 rp64 kernel: ata1: hard resetting link
Aug 08 19:57:24 rp64 kernel: ata1: softreset failed (1st FIS failed)
Aug 08 19:57:24 rp64 kernel: ata1: reset failed, giving up
Aug 08 19:57:24 rp64 kernel: ata1.00: disabled
Aug 08 19:57:24 rp64 kernel: ata1: EH complete
Aug 08 19:57:24 rp64 kernel: sd 0:0:0:0: [sda] tag#5 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=60s
Aug 08 19:57:24 rp64 kernel: sd 0:0:0:0: [sda] tag#5 CDB: Write(10) 2a 00 01 40 41 00 00 05 40 00
Aug 08 19:57:24 rp64 kernel: blk_update_request: I/O error, dev sda, sector 20988160 op 0x1:(WRITE) flags 0x4800 phys_seg 168 prio class 0
Aug 08 19:57:24 rp64 kernel: sd 0:0:0:0: [sda] tag#6 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=60s
Aug 08 19:57:24 rp64 kernel: sd 0:0:0:0: [sda] tag#6 CDB: Write(10) 2a 00 01 40 3e 40 00 02 c0 00
Aug 08 19:57:24 rp64 kernel: blk_update_request: I/O error, dev sda, sector 20987456 op 0x1:(WRITE) flags 0x0 phys_seg 88 prio class 0
Aug 08 19:57:24 rp64 kernel: sd 0:0:0:0: [sda] tag#7 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s
Aug 08 19:57:24 rp64 kernel: sd 0:0:0:0: [sda] tag#7 CDB: Read(10) 28 00 00 01 29 08 00 00 08 00
Aug 08 19:57:24 rp64 kernel: blk_update_request: I/O error, dev sda, sector 76040 op 0x0:(READ) flags 0x3000 phys_seg 1 prio class 0
Aug 08 19:57:24 rp64 kernel: EXT4-fs warning (device sda1): htree_dirblock_to_tree:1004: inode #2: lblock 0: comm ls: error -5 reading dir>
Aug 08 19:57:24 rp64 kernel: sd 0:0:0:0: [sda] tag#8 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s
Aug 08 19:57:24 rp64 kernel: sd 0:0:0:0: [sda] tag#8 CDB: Write(10) 2a 00 01 40 46 40 00 02 c0 00
Aug 08 19:57:24 rp64 kernel: blk_update_request: I/O error, dev sda, sector 20989504 op 0x1:(WRITE) flags 0x800 phys_seg 88 prio class 0
Aug 08 19:57:24 rp64 kernel: sd 0:0:0:0: [sda] tag#9 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s
Aug 08 19:57:24 rp64 kernel: sd 0:0:0:0: [sda] tag#9 CDB: Write(10) 2a 00 0e 84 08 00 00 00 08 00
Aug 08 19:57:24 rp64 kernel: blk_update_request: I/O error, dev sda, sector 243533824 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
Aug 08 19:57:24 rp64 kernel: Buffer I/O error on dev sda1, logical block 30441472, lost sync page write
Aug 08 19:57:24 rp64 kernel: JBD2: Error -5 detected when updating journal superblock for sda1-8.
Aug 08 19:57:24 rp64 kernel: sd 0:0:0:0: [sda] tag#10 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=60s
Aug 08 19:57:24 rp64 kernel: Aborting journal on device sda1-8.
Aug 08 19:57:24 rp64 kernel: sd 0:0:0:0: [sda] tag#10 CDB: Write(10) 2a 00 01 40 39 00 00 05 40 00
Aug 08 19:57:24 rp64 kernel: sd 0:0:0:0: [sda] tag#14 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s
Aug 08 19:57:24 rp64 kernel: blk_update_request: I/O error, dev sda, sector 20986112 op 0x1:(WRITE) flags 0x4000 phys_seg 168 prio class 0
Aug 08 19:57:24 rp64 kernel: sd 0:0:0:0: [sda] tag#14 CDB: Write(10) 2a 00 0e 84 08 00 00 00 08 00
Aug 08 19:57:24 rp64 kernel: blk_update_request: I/O error, dev sda, sector 243533824 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
Aug 08 19:57:24 rp64 kernel: blk_update_request: I/O error, dev sda, sector 243533824 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
Aug 08 19:57:24 rp64 kernel: Buffer I/O error on dev sda1, logical block 30441472, lost sync page write
Aug 08 19:57:24 rp64 kernel: JBD2: Error -5 detected when updating journal superblock for sda1-8.
Aug 08 19:57:24 rp64 kernel: EXT4-fs error (device sda1) in ext4_init_inode_table:1459: IO failure
Aug 08 19:57:24 rp64 kernel: sd 0:0:0:0: [sda] tag#11 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s
Aug 08 19:57:24 rp64 kernel: sd 0:0:0:0: [sda] tag#11 CDB: Write(10) 2a 00 00 00 08 00 00 00 08 00
Aug 08 19:57:24 rp64 kernel: blk_update_request: I/O error, dev sda, sector 2048 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
Aug 08 19:57:24 rp64 kernel: blk_update_request: I/O error, dev sda, sector 2048 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
Aug 08 19:57:24 rp64 kernel: Buffer I/O error on dev sda1, logical block 0, lost sync page write
Aug 08 19:57:24 rp64 kernel: EXT4-fs (sda1): I/O error while writing superblock
Schaut also nicht richtig gut auf .
Bevor ich jetzt auf Verdacht eine ander SSD kaufe, hat jemand SSDs am SATA Kontroller erfolgreich am laufen?
Und wenn ja welche?
Vielen Dank und viele Grüße
gabs5807
Btw. Die serielle Konsole war bei mir ziemlich unleserlich. Stimmt den das mit der Geschwindikeitsangabe? Die maximale war doch eigentlich 11500 baut, oder ?
Ne Menge Stoff zum Antworten. Mal auf die Schnelle, ein paar Sätze.
Im SPI kommt der u-boot rein, der bei den anderen Images in den ersten 16k drin sein sollte. Wenn der u-boot im SPI ist, sucht er nach bootbaren Devices. Dann sollte er auch problemlos vom eMMC booten. Ich glaube meines habe ich irgendwie mal geschrottet, das will hier nicht mehr. Aber auch nicht so wichtig, für mich.
Den Rest muss ich mal in Ruhe lesen und versuchen zu verstehen. Aber Du hast da ein paar sehr interessante Dinge geschrieben.
Im Fediverse -> @FrankM@nrw.social
Entweder
oder
"Das U-Boot" Source Tree. Contribute to ayufan-rock64/linux-mainline-u-boot development by creating an account on GitHub.
GitHub (github.com)
Das Image auf eine SD-Karte und den ROCKPro64 damit starten. Gut ist es, wenn man mittels UART mitlesen kann. Bei Kamils Image blinkt irgendwann die weiße LED, wenn ich mich recht erinnere.
Im Fediverse -> @FrankM@nrw.social
