@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
Und deswegen vielen Dank für den wichtigen Hinweis, das sich da was getan hat.
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
@FrankM sagte in bootconsole [uart8250] disabled:
Entweder
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
Im Fediverse -> @FrankM@nrw.social
@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 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.