13.1-RELEASE-arm64-aarch64-RPI und uboot.bin

berni51

Open-Net-FreeBSD user
Weiss jemand, ob das uboot-Problem von 13.0 auf dem Raspberry 4 mit 13.1 immer noch besteht? Hab gerade 2 Raspis aufzusetzen, und ehe ich's selber probier, frag ich mal bei euch.

Code:
The u-boot.bin used when creating 13.0-RELEASE image was too old to support newer RPi4 hardware revision.

The workaround is replacing u-boot.bin with newer one from sysutils/u-boot-rpi4:

# pkg install -y u-boot-rpi4
# mdconfig -f FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img
md0
# mount_msdosfs /dev/md0s1 /mnt
cp /usr/local/share/u-boot/u-boot-rpi4/u-boot.bin /mnt/u-boot.bin
# umount /mnt
mdconfig -d -u 0
 
Ich hab einen "Standard Pi4 8GB" mit dem aktuellen 13.1-RELEASE Image am laufen :)

Code:
root@raspberry-fbsd:~ # inxi -FzS
System:
  Kernel: FreeBSD 13.1-RELEASE arm64 bits: 64 Console: pty pts/0 OS: FreeBSD 13.1-RELEASE
Machine:
  Type: Desktop Mobo: N/A model: N/A serial: N/A UEFI: U-Boot v: 2021.07 rev: 21.7
    date: 05/12/2022
CPU:
  Info: quad core model: ARM Cortex-A72 r0p3 bits: 64 type: MCP
  Speed: N/A min/max: N/A cores: No OS support for core speeds.
Graphics:
  Message: No ARM data found for this feature.
  Display: server: No display server data found. Headless machine? tty: 165x48
  Message: Advanced graphics data unavailable in console for root.
Audio:
  Message: No ARM data found for this feature.
  Sound Server-1: OSS v: 2009061500 running: yes
Network:
  Message: No ARM data found for this feature.
  IF-ID-1: genet0 state: active speed: 1000baseT duplex: full-duplex mac: <filter>
RAID:
  Device-1: zpi type: zfs status: ONLINE level: linear raw: size: 59 GiB free: 52.4 GiB zfs-fs:
    size: 57.17 GiB free: 46.41 GiB
  Components: Online: 1:
Drives:
  Local Storage: total: raw: 59.48 GiB usable: 175.65 GiB used: 6.61 GiB (3.8%)
  ID-1: /dev/mmcsd0 model: SDHC SC64G 8.0 size: 59.48 GiB scheme: GPT
Partition:
  ID-1: / size: 48.16 GiB used: 1.74 GiB (3.6%) fs: zfs logical: zpi/ROOT/default
  ID-2: /tmp size: 46.41 GiB used: 136 KiB (0.0%) fs: zfs logical: zpi/tmp
  ID-3: /usr/home size: 46.41 GiB used: 168 KiB (0.0%) fs: zfs logical: zpi/usr/home
  ID-4: /var/log size: 46.41 GiB used: 832 KiB (0.0%) fs: zfs logical: zpi/var/log
  ID-5: /var/tmp size: 46.41 GiB used: 96 KiB (0.0%) fs: zfs logical: zpi/var/tmp
Swap:
  ID-1: swap-1 type: partition size: 4 GiB used: 8.6 MiB (0.2%) dev: /dev/zvol/zpi/swap
Sensors:
  System Temperatures: cpu: 53.5 C mobo: N/A
  Fan Speeds (RPM): N/A
Info:
  Processes: 63 Uptime: 27d 12h 23m Memory: 7.84 GiB used: 4.04 GiB (51.6%) Init: init (BSD)
  Shell: csh inxi: 3.3.11
root@raspberry-fbsd:~ #
 
Ich hab einen "Standard Pi4 8GB" mit dem aktuellen 13.1-RELEASE Image am laufen :)

Code:
Machine:
  UEFI: U-Boot v: 2021.07 rev: 21.7 date: 05/12/2022
BTW: Benutzt Du auch wireguard mit deinem PI4 und 13.1-R? Wenn ja, wie sind die Ausgaben von:
Code:
pkg info wireguard-kmod
kldstat | grep -i if_wg
? Danke.
 
Ich hab einen "Standard Pi4 8GB" mit dem aktuellen 13.1-RELEASE Image am laufen :)
Hatte ich ja auch schon mal, aber jetzt hab ich 2 hier Standard 8GB-Pi's, auf denen FBSD nicht bootet. Beide hängen im uboot.
NetBSD und ein Debian laufen einwandfrei. Muss ich wohl mal diesen workaround probieren.
 
Sorry Leute, der Fehler saß mal wieder vorm Bildschirm! :cool:
Die Ursache war folgende:
Ich hab hier etliche 128GB SSD liegen, die ich anstelle von Sticks oder SD-Karten benutze. Oder auch als Datenträger für Raspis und ähnliche Kleincomputer. Die steck ich in ein kleines Gehäuse und schliesse sie via USB an.
Die Platten sind alle direkt aus China, und wenns bei Ali was günstiges gab, hab ich gekauft. Jedenfalls liegen hier jede Menge dieser SSD und ebenso etliche Gehäuse.
Die meisten der SSD sind ngff's, aber es sind auch nvme's darunter. Für beide Typen hab ich passende Gehäuse.

Jetzt, beim Versuch mit FreeBSD auf den Raspis hab ich zufällig 2x nvme SSDs genommen, ohne darauf zu achten. Und tja, was soll ich sagen: Die Raspis booten die nvme nicht. Ist mir vorher nie aufgefallen, und weil ja alles via USB geht, kam ich auch nicht drauf. Den amd86 Rechnern ist das wurscht, die booten alles, aber die Raspis nicht, jedenfalls diese beiden nicht.
Jedenfalls booten die Raspis jetzt mit ngff via USB auch ein 13.1 problemlos.
Wollte ich euch nur kurz mitteilen. :rolleyes:
 
Vermutlich musst du mal das eeprom aktualisieren. Das ist leider in ständiger Entwicklung.


Wegen den SD Karten: Ich nutze immer sog. Heavy Endurance Versionen Bsp. Von Samsung oder Kingston. Früher hatte ich normale billige Handykarten die gingen schnell im Raspi kaputt egal welches FS. Diese Karten sind halt nicht ganz billig.

Die hier läuft seit 2 Jahren Dauerbetrieb in einem anderen Raspi.


Laut Hersteller könnte man auf die Karte 10 Jahre permanent drauf schreiben.....

Laut CT Test hab ich die Version damals ausgesucht weil ich schon mehrfach defekte Karten hatte. Der Text war im Raspi Sonderheft 2020.
 
Zuletzt bearbeitet:
Ich glaube wenn man nen Raspi für irgendwas richtung "Läuft dauerhaft mehr als nen Codi drauf" nutzt ist es nicht ganz blöd ne "richtige" SSD zu verwenden.
 
@schorsch_76 : Läuft dein raspi headless?
Falls nicht, welche Auflösung hast Du auf der Console?

Hintergrund der Frage ist, dass bei den beiden neuen raspi der Eintrag hdmi_safe=1 in der config.txt dazu führt, dass die nur noch über die Netzwerkkarte booten wollen. Bei meinen älteren raspi 4 konnte ich damit eine 1080 Auflösung herbeiführen.
 
Ja, der läuft headless. Ich habe auf ihm meinen Webserver, Mailserver, VPN und Datenbanken (psql) am laufen. Backup läuft natürlich automatisch auf das nas welches vorher per WOL geweckt wird. Für die öffentliche statische ipv4/6 (für Mail) hab ich einen vps mit reiner gateway Funktion Hetzner für 3€/mon.
 
Wegen den SD Karten: Ich nutze immer sog. Heavy Endurance Versionen Bsp. Von Samsung oder Kingston. Früher hatte ich normale billige Handykarten die gingen schnell im Raspi kaputt egal welches FS.
Oder man setzt ein Betriebssystem ein, welches für die im Raspberry Pi 4 eingelegte Micro-SD-Karte Unterstützung für den TRIM- aka ERASE-Befehl bietet. Nicht nur SSD's benötigen für höchste Performance und eine lange Lebensdauer regelmässige TRIM-Befehle. Auch per USB-Kabel angeschlossene Datenträger (zum Beispiel: USB-Memorystick) und SD-Karten aller Grössen benötigen regelmässige TRIM-Befehle, damit sie höchste Performance liefern können und möglichst lange leben.

Ubuntu 20.04 LTS unterstützt den TRIM- aka ERASE-Befehl für die im Raspberry Pi 4 eingelegte Micro-SD-Karte. Nachtesten kann man dies unter Linux wie folgt:
Seite 2 beachten!

Unter Linux empfehle ich den Einsatz von XFS. Alle anderen Dateisystemen haben sich mit Linux im harten Raspberry-Einsatz NICHT bewährt. Siehe dazu:

Ob FreeBSD den TRIM- aka ERASE-Befehl beim Einsatz des Raspberry Pi 4 unterstützt, wäre zu testen. Für weitere Informationen zum TRIM-Befehl siehe:

Die fehlende Unterstützung des TRIM- aka ERASE-Befehl für die im Raspberry Pi 4 eingesetzte Micro-SD-Karte wäre für mich bereits ein "NO-GO-Kriterium" für den Einsatz von FreeBSD.
 
Zuletzt bearbeitet:
Musste bei meinen "ersten Gehversuche mit FreeBSD@Raspberry Pi" mit dem offiziellen FreeBSD-Image:

Code:
# sha256sum /tmp/FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img
ef375b4faa966d3d3ca94420e3c04305d63168641081dd921860f195de06eb6c  /tmp/FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img

nach dem Überspielen des Images (*.img nach Micro-SD-Karte) unter Linux mit dem Befehl:

Code:
# dd bs=4M status=progress if=/tmp/FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img of=/dev/sdc

die FAT32-Bootpartition der Micro-SD-Karte mit dem korrekten FAT-Label versehen, damit der Raspberry Pi mit FreeBSD ab der Micro-SD-Karte bootet. Unter Linux geht dies wie folgt:

Code:
# fatlabel /dev/sdc1 system-boot

Ergibt zum Beispiel für Ubuntu 20.04 LTS folgende Partitonstabelle auf der im Raspberry Pi 4 eingesetzten Micro-SD-Karte:

Code:
# cfdisk --zero /dev/sdc
=> dos

# cfdisk /dev/sdc
Gerät Boot Anfang Grösse Kn Typ Bezeichnung Dateisystem Typ
/dev/sdc1 * 2048 256MB c W95 FAT32 (LBA) system-boot FAT32 Primär
/dev/sdc2 Rest 83 Linux writable xfs Primär

Vielleicht hilft dieser Tipp weiter...
 
@GrandDixence Ich kann nur sagen, daß es bei mir soweit läuft und ich mit den guten Sd Karten keine Probleme habe. "Früher" (tm) hat man ja auch immer gesagt wenn man Probleme mit zfs hatte, dass ohne ECC RAM Zfs nicht sinnvoll einsetzbar ist. Man solle eben gute Hardware nutzen. Ich sehe das hier ähnlich. Gute SD Karten und es läuft. :)
 
@GrandDixence Ich kann nur sagen, daß es bei mir soweit läuft und ich mit den guten Sd Karten keine Probleme habe. "Früher" (tm) hat man ja auch immer gesagt wenn man Probleme mit zfs hatte, dass ohne ECC RAM Zfs nicht sinnvoll einsetzbar ist. Man solle eben gute Hardware nutzen. Ich sehe das hier ähnlich. Gute SD Karten und es läuft. :)
Kann ich nur bestätigen! Hab vor über 3 Jahren zwei NUC eingerichtet, die als NFS, WebDav- und Web-Server laufen. EIn minimales FreeBSD läuft dort auf SD-Karten. Unterhalb der Qualität von z.B. ScanDisk Ultra kommt da nichts rein.
Ein bewusster Versuch mit einer 256GB chinesischen SD-Karte ist nach wenigen Tagen Betrieb grandios gescheitert.
Dennoch liegen natürlich gespiegelte Ersatzkarten immer bereit, wurden aber bisher nicht benötigt.

Brauche ich aber mehr Performance durch den Einsatz verschiedener Applikationen wie jetzt gerade bei den beiden Raspis, greife ich ins SSD-Lager.
 
Brauche ich aber mehr Performance durch den Einsatz verschiedener Applikationen wie jetzt gerade bei den beiden Raspis, greife ich ins SSD-Lager.
Vor allem muss man sehen, dass der RPi 4 letztendlich billige Low-End Hardware und keine High-End Workstation ist. Das meine ich gar nicht negativ. Man setzt den RPi 4 schließlich ein, da er günstig und verfügbar ist, außerdem wenig Strom verbraucht. Aber wenn mir die Performance einer "kostenoptimalen" SD-Karte nicht reicht, nehme ich gleich Hardware einer höheren Klasse. Ich meine, das Ding hat nicht mal einen UHS-II Slot und selbst wenn er es hätte, sind MicroSD-Karten da doch recht limitiert.
 
Jo, alles richtig. Ein Pi4 mit 8GB und externer SSD ist aber doch für vieles ausreichend perfomant. Und langlebig sind die meist auch. Hier im Umfeld laufen noch etliche Pi3 mit Raspian seit Jahren vor sich hin.

Als NFS/WebDav/Web-Server würde ich allerdings keinen Pi mehr nehmen. Hab ich (natürlich) probiert, aber mit der Verwaltung von zig TB Platten mit ZFS sind Prozessor und RAM sehr schnell in die Knie gegangen. Da kamen dann die NUCs mit i5 und 16 GB RAM ins Spiel. Ist schon ein Unterschied, und nicht nur im Preis.
Bleibt aber genug für die Pi zu tun, im Moment als Xeoma-Server zur Kamera-Verwaltung bzw. auch zur Anzeige.
 
Gerade gelernt: openzfs kann auch TRIM :)


Code:
root@raspberry-fbsd:~ # zpool trim zpi
root@raspberry-fbsd:~ # zpool status -t zpi
  pool: zpi
 state: ONLINE
config:

        NAME                 STATE     READ WRITE CKSUM
        zpi                  ONLINE       0     0     0
          gpt/FreeBSD%20ZFS  ONLINE       0     0     0  (95% trimmed, started at Fri Jun 24 18:03:50 2022)
                                                                                                                                                                     
errors: No known data errors
 
Zurück
Oben