bootconsole [uart8250] disabled

[FrankM]

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

[gabs5807]

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 ?

[FrankM]

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.

[FrankM]

Die Geschwindigkeitsangabe beim UART von 1500000 ist richtig. Es gibt aber einige Adapter, die das nicht können!

[gabs5807]

@FrankM Kann ich in den SPI den u-boot von der SD-Karte rein flashen, oder brauche ich dafür einen eigenen?
Und gibt es da unter Linux ein tool dafür? Ich habe gelesen, löschen geht unter linux(?).

[FrankM]

Entweder

Pipelines

(dev.azure.com)

oder

Releases · ayufan-rock64/linux-mainline-u-boot

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

[gabs5807]

@FrankM sagte in bootconsole [uart8250] disabled:

Entweder

Pipelines

(dev.azure.com)

oder

Releases · ayufan-rock64/linux-mainline-u-boot

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

Ich habe mal das u-boot-flash-spi-rockpro64.img.xz und das u-boot-rockpro64-2020.01-ayufan-2014-gff2cdd38.deb des zweiten Link probiert.
Das img bootet mein installiertes debian, ohne dass das spi geflashed wird . Das deb lässt sich installierten (nachdem ein paar dependencies nachinstalliert wurden), das Skript erkennt aber das Board nicht:

root@rp64:~# /usr/local/sbin/rock64_write_spi_flash.sh
Cannot detect board from u-boot-rockpro64-2020.01-ayufan-2014-gff2cdd38.
root@rp64:~#

Seltsam .

Den anderen Link habe ich noch nicht getestet, da muss man sich zum download anmelden, oder?
Ich kann es so nicht öffen oder runterladen .

Viele Grüße

Gabs5807

[FrankM]

Hast Du dein Image auf das eMMC Modul installiert?

Wenn ja, das Modul beim Booten der Images bitte abschalten.

[gabs5807]

@FrankM sagte in bootconsole [uart8250] disabled:

Hast Du dein Image auf das eMMC Modul installiert?

Wenn ja, das Modul beim Booten der Images bitte abschalten.
Vielen Dank für den Hinweis. Habe gelesen aber leider vergessen .
Werde ich machen, ich das Gehäuse noch mal öffnen muss und die SSD weil ich noch austauschen muss.
Viele Grüße

[gabs5807]

@gabs5807 sagte in bootconsole [uart8250] disabled:

@FrankM sagte in bootconsole [uart8250] disabled:

Hast Du dein Image auf das eMMC Modul installiert?

Wenn ja, das Modul beim Booten der Images bitte abschalten.
Vielen Dank für den Hinweis. Habe gelesen aber leider vergessen .
Werde ich machen, ich das Gehäuse noch mal öffnen muss und die SSD weil ich noch austauschen muss.
Viele Grüße

Das flashen des SPI hat jetzt wie beschrieben funktioniert . Vielen Dank.