Yeah, genau das worauf ich auch warte.
Wenn ich das richtig mitbekommen habe, könnte das Kamil's nächster Punkt auf seiner Liste sein.
Mal wieder was, in meinen Augen interessantes. Durch einen Zufall ist mir folgendes aufgefallen.
Wenn ich den neuen u-boot 1045 in den SPI schreibe und dann versuche von der am USB3-Port angeschlossenen HDD zu booten, passiert nichts. Wie gewohnt, er findet kein bootbares Device.
Durch einen Zufall ist mir dann folgendes aufgefallen.
rock64@rockpro64:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 992M 0 992M 0% /dev
tmpfs 200M 852K 199M 1% /run
/dev/sda7 110G 3.8G 102G 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/sda6 112M 4.0K 112M 1% /boot/efi
tmpfs 200M 0 200M 0% /run/user/1000
Wie man sieht, ist die HDD (sda) hier jetzt /boot und /root
Ab und zu passierte aber noch das hier.
rock64@rockpro64:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 992M 0 992M 0% /dev
tmpfs 200M 852K 199M 1% /run
/dev/sda7 110G 3.8G 102G 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/mmcblk1p6 112M 4.0K 112M 1% /boot/efi
tmpfs 200M 0 200M 0% /run/user/1000
Hier ist das /boot Device auf dem eMMC-Modul gemountet. Hmm? Nicht schön, wenn man mal den Kernel usw. aktualisieren will. Ich habe dann mal was getestet, ohne wirklich zu begreifen, ob es hilft. Aber, Versuch macht klug.
Bin dann hingegangen und habe die Bootpartition auf dem eMMC-Modul gelöscht.
Wenn man den Kernel updatet wird zwar /boot von der sda benutzt, er nutzt aber nicht diesen /boot beim Starten. Muss noch weiter testen.
Hier ein sauberer Log pastebin.com
Auch nach dem ich jetzt x-mal neugebootet habe, ist mir nichts negatives aufgefallen. Scheint sauber zu funktionieren. ABER, ich verstehe überhaupt nicht warum das so geht und mit u-boot im SPI nicht!?!?
Für denjenigen, der gerne ein System von USB3 starten möchte, ist das jetzt im Moment vielleicht eine praktikable Lösung.