Beiträge von schlizbäda

    So wie das OS auf dem RPi konfiguriert ist, gibt es den User root ja nur indirekt über sudo und damit können sich nur bestimmte "normale" User als root anmelden und zwar mit ihrem persönlichen Passwort. Damit ein normaler User sudo nutzen darf, muss seine Kennung in der Datei /etc/sudoers eingetragen sein.

    Das ist jetzt meine Billigerklärung als Linux-Dauernoob.
    :2cents:

    Hi El_Codepone ,

    wenn die "normalen" RPis so vor dem Betrachter liegen, dass die LAN- und USB-Buchsen nach rechts schauen, ist die GPIO-Leiste zum Anstecken hinten und schaut nach oben. Beim Anstecken eines HAT, wie z.B. dem Sense HAT schauen dann die LEDs und die anderen Bedienelemente nach oben, sie liegen also ergonomisch vor dem Betrachter. Anders beim RPi400, bei dem die GPIO-Pins nach hinten schauen: Da kann man natürlich auch ein HAT anstecken, aber dessen Bedienelemente schauen dann auch nach hinten und vom Nutzer des RPi400 weg! Das ist äußerst unpraktisch, siehe die Bilderstrecke im ersten Beitrag (bitte per Mausklick aufklappen).

    Der Sinn des RPi400extBrds liegt zum einen darin, dieses Board hinten am RPi400 anzustecken und dann die gewünschten HATs am RPi400 so aufstecken zu können, wie man es von den anderen RPis gewohnt ist, nämlich dass die Bedienelemente nach oben schauen, siehe hier. Man sieht an der Hinterseite des RPi400 das RPi400extBrd (untere grüne Platine) und darauf aufgesteckt das Sense HAT im Betrieb.

    Da die Platine groß genug sein muss, um ein konformes Pi HAT aufstecken zu können, habe ich mir gedacht, die freie Fläche für (in meinen Augen) sinnvolle Funktionen zu nutzen. Da kam ich dann zuallererst auf eine I2S-Soundkarte, da mir am RPi400 die Audioausgabe (außer über HDMI) komplett fehlt. Als Ergänzung zum I2S-DAC PCM5122 (Audiodekoder, Digital-/Analogwandler, Vorverstärker) habe ich einen kleinen Audioverstärker hinzugefügt wie beim Hifiberry MiniAmp, aber nicht als digitalen Class-D-Verstärker, sondern mit dem LM4838 als klassischen analogen Gegentaktverstärker (Class-AB).
    Nachdem noch Platz frei war, entschied ich mich noch für eine UART-Anbindung des RPi400 über USB mittels des FTDI-Bausteins FT232RNL ("RS232", Virtual COM-Port) sowie für eine RTC. Den RPi5 mit integrierter RTC gab's ja damals noch nicht...

    Wichtig ist, dass die drei Komponenten (Audio, UART, RTC) voneinander unabhängig sind. Der Audioteil gliedert sich auf in den I2S-DAC, dessen analoge Ausgangssignale direkt als Eingangssignal für einen (großen) Audioverstärker einer Stereoanlage verwendet werden können, und einen integrierten Kleinverstärker, an den direkt 4R-Lautsprecher angeschlossen werden können. Zum Beispiel kleine passive PC-Boxen oder aber auch hochwertige HK-Audio-Boxen PR:O 10X, die dann selbst mit den 2W des LM4838 eine ordentliche Mucke abgeben.

    Folgende Varianten von meinem RPi400extBrd kann ich anbieten:

    • nacktes Board nur mit den Buchsen- und Stiftleisten für die mechanische GPIO-Umsetzung
    • Board nur mit Audio (I2S-DAC + Kleinverstärker)
    • Audioboard zusätzlich mit UART
    • Audioboard zusätzlich mit RTC
    • Audioboard zusätzlich mit UART + RTC (Vollausstattung)

    Die Variante nur mit I2S-DAC auf Cinchausgang ohne Verstärker kann ich derzeit noch nicht anbieten, da mir hier der saudumme Layoutfehler unterlaufen ist.

    Ich hoffe ich konnte mit diesen Ausführungen etwas Klarheit schaffen.

    Eine Art Vorab-Werbeflyer gibt es hier:
    https://forum-raspberrypi.de/attachment/34259-rpi400extbrd-de-prototypen-pdf/

    Wenn Du mit dem RPi400 Musik hören willst, kann ich nur zur I2S-Soundkarte raten und da zur schweizer Firma Hifiberry. Speziell für den 400er habe ich ein Derivat, das RPi400extBrd gemacht. Achtung: Leider habe ich da noch einen Layoutfehler drin, der die Cinchbuchsen für den Vorverstärkerausgang betrifft! Von daher wird mein Board für Dich eher nichts sein.

    So wie Du es aber beschreibst, willst Du Musik machen und da würde ich tatsächlich zu einem "richtigen" Computer tendieren. Wenn Du ganz spezielle Komponenten verwendest wie ich als DJ, musst Du auch Obacht geben, dass die Hardware linuxkompatibel ist! Bei Schnellkäufen bist Du u.U. an Windows oder MAC OS gebunden.
    (Auch ich habe die Schnauze von Windows, insbesondere 10 und 11, gestrichen voll)

    EDIT:
    Die meiste freie Software (z.B. Audacity oder für DJs Mixxx) gibt es, weil open source, sowohl für Linux als auch für andere Betriebssysteme. Mit proprietärer Software bindet man sich ebenfalls schnell an proprietäre Betriebssysteme.

    Outlaw
    Es geht eigentlich darum, wenn man die RTC auf meinem Board (oder irgendein anderes RTC-Board) nutzen will und nicht die interne RTC vom RPi5, z.B. weil man einen existierenden und funktionierenden Aufbau für einen RPi <= 4 hat. Im Spoiler 4 meines obigen Beitrags beschreibe ich, wie man den Treiber für die interne RTC des RPi5 deaktivieren kann und dann einen beliebigen anderen Treiber (hier für DS3231) aktiviert.
    Ein "Schlamassel" (ok, das Wort ist an dieser Stelle etwas hart!) ist es deswegen, weil der symbolische Link /dev/rtc bei allen RPis auf /dev/rtc0 zeigt, was beim RPi5 etwas anderes ist (nämlich die interne RTC) als bei den älteren RPis. Einen Linux-Dauernoob wie mich kann so etwas ganz schön ausbremsen...

    Ich kenne Deine Platine nicht aber kann man da nicht auch den RTC deaktivieren/ignorieren

    Ich plane ja immer noch, das RPi400extBrd nach Beseitigung kleinerer Fehlerchen in verschiedenen Konfigurationen zu vertreiben und da gibt es dann auch eine Variante ohne bestückter RTC. Ferner werde ich den I2C-Bus per Jumper-Steckbrücke abtrennbar gestalten.

    Inbetriebnahme des RPi400extBrds am RPi5

    Inhaltsverzeichnis dieses Threads
    • Beitrag #1 (dieser Beitrag)
      Inbetriebnahme am grafischen Desktop unter Raspberry Pi OS bookworm Desktop (Audiosystem PipeWire)
    • Beitrag #5
      Inbetriebnahme unter Raspberry Pi OS bookworm lite (Audiosystem ALSA)

    Hier beschreibe ich die Inbetriebnahme meines RPi400extBrds auf einem Raspberry Pi 5 unter Raspberry Pi OS bookworm Desktop vom 05.12.2023. Dieses Tutorial soll vor allem dazu dienen, folgende Komponenten des Boards auf dem RPi5 unter bookworm zum Laufen zu bringen:

    Es ist nämlich im Gegensatz zu früher beim RPi5 mitnichten so, dass man eine SD-Karte für einen RPi <= 4 einsteckt und die Sache läuft. Der 5er ist eine Diva, die will schon etwas mehr Aufmerksamkeit :bussi2: Die Probleme sind aber nicht spezifisch für mein RPi400extBrd, sondern treten genauso bei kleinen RTC-Breakoutboards (z.B. von Adafruit) auf oder bei den diversen I2S-Soundkarten von HiFiBerry.

    Dieses Tutorial wurde unter Raspberry Pi OS bookworm Desktop vom 05.12.2023 in beiden Varianten, 32bit und 64bit getestet. Wenigstens diesbezüglich gibt es keine Unterschiede.
    Alle Programmausgaben und Screenshots beziehen sich auf die 64bit-Variante.
    Mein Dank gilt insbesondere Jürgen Böhm , der mir seinen RPi5 zum Testen zur Verfügung gestellt hat :danke_ATDE:

    1. Anforderungen an die Leser des Tutorials
    • Flashen einer SD-Karte mit einem Image von Raspberry Pi OS.
    • Öffnen eines Terminalfensters in der Desktopumgebung von Raspberry Pi OS
    • Grundsätzliche Anwendung von Texteditoren (z.B. nano)
    • Bedeutung von /boot/firmware/config.txt,
      insbesondere die Tatsache, dass die jetzt (ab bookworm) unter /boot/firmware liegt und nicht mehr unter /boot. Siehe u.a. hier
    2. Betriebssystem herunterladen und vorbereiten, raspi-config

    Die Betriebssystem-Images wurde von https://www.raspberrypi.com/software/operating-systems/ heruntergeladen und anschließend auf eine SD-Karte geflasht. Wie dies z.B. mit dem RPi-Imager gemacht wird, ist hier beschrieben und ich unterstelle das entsprechende Wissen des Lesers.

    Nach dem ersten Hochfahren das System aktualisieren. Dazu wird in der Eingabezeile des Terminalfensters folgendes Kommando abgesetzt:
    sudo apt-get update && sudo apt-get upgrade

    Kontrolle der Version des Betriebssystems:
    uname -a

    Code
    Linux raspberrypi 6.1.0-rpi8-rpi-2712 #1 SMP PREEMPT Debian 1:6.1.73-1+rpt1 (2024-01-25) aarch64 GNU/Linux

    Hier ist wichtig, dass nach dem Update eine Version vom 25.01.2024 oder neuer vorliegt!

    Konfiguration des Betriebssystems mit raspi-config:
    sudo raspi-config

    In raspi-config werden in folgenden Menüpunkten die Einstellungen angepasst:

    3 Interface Options
        I1 SSH          Would you likle the SSH server to be enabled?  yes (nicht zwingend notwendig, aber immer wieder praktisch...)
        I4 I2C          Would you like the ARM I2C interface to be enabled?)  yes
        I5 Serial Port  Would you like a login shell to be accessible over serial?  no
                        Would you like the serial port hardware to be enabled?  yes
    5 Localisation Options
        L4 WLAN Country Select the country in which the Pi is to be used  DE

    3. UART-Verbindung von USB (FT232RNL) nach RPi-UART: GPIO14 (TxD) und GPIO15 (RXD)

    Voraussetzung ist, dass die beiden linken UART-Jumper (rot markiert) gebrückt sind, damit zwischen FTDI-RXD und RPi-GPIO14 (TXD) sowie zwischen FTDI-TXD und RPi-GPIO15 (RXD) eine Verbindung besteht, siehe Bild:

    Außerdem muss der FTDI-UART über die USB-Mini-Buchse des RPi400extBrds mit einem USB-Anschluss des RPi5 verbunden werden.

    Prüfen, ob die Gerätedateien der UART-Schnittstellen vorhanden sind:
    ls -l /dev/tty????

    Code
    crw-rw---- 1 root dialout 204, 64  4. Feb 22:11 /dev/ttyAMA0
    crw-rw---- 1 root dialout 188,  0  4. Feb 22:52 /dev/ttyUSB0

    Dabei ist /dev/ttyAMA0 die UART-Schnittstelle an den RPI-GPIOs und /dev/ttyUSB0 die vom FTDI-Chip per USB zur Verfügung gestellte Schnittstelle.

    Zum Test der seriellen Schnittstelle wird das Konsolenprogramm minicom installiert:
    sudo apt-get install minicom
    Der Test der seriellen Verbindung von USB zum RPi-UART mit minicom ist im Beitrag #37 meines Threads RPi400extBrd: schlizbäda's Extension Board für den Raspberry Pi 400 mit Soundkarte, RTC und UART beschrieben.

    Fazit:

    1. Die serielle Schnittstelle des RPi5 wird wie bei den Vorgängermodellen entweder mit raspi-config über den Menüpunkt 3 Interface Options --> I5 Serial Port oder (gleichwertig) über den Eintrag dtparam=uart0=on in /boot/firmware/config.txt aktiviert.
    2. Die FTDI-Schnittstelle des FT232RNL über USB wird durch den Linuxkernel zur Verfügung gestellt, sobald er über USB am RPi5 angesteckt wird.
    3. Am RPi (nicht nur beim 5er) funzt der FTDI sowohl an den USB2- als auch an den USB3-Ports.
    4. Real Time Clock (RTC)

    Der RPi5 hat im Gegensatz zu seinen Vorgängern bis einschließlich RPi4(00) eine eingebaute RTC, die als Gerätedatei /dev/rtc0 zur Verfügung gestellt wird. Weitere externe RTCs wie die DS3232 auf dem RPi400extBrd werden dann als /dev/rtc1 etc. bereitgestellt. Bei den RPis < 5 fehlt die on-board-RTC und externe RTCs werden als /dev/rtc0 angelegt. Das wäre jetzt weiter nicht soo schlimm, aber das Blöde ist, dass der symbolische Link /dev/rtc immer auf /dev/rtc0 zeigt. (Nicht nur) die grafische Oberfläche von Raspberry Pi OS verwendet die Gerätedatei /dev/rtc und damit beim RPi5 die interne RTC.

    Um dieses Schlamassel zu beseitigen, müssen in der /boot/firmware/config.txt folgende Einträge vorgenommen werden:

    Code
    dtparam=rtc=off
    dtoverlay=i2c-rtc,ds3231

    Die erste Zeile deaktiviert die interne RTC des RPi5
    Die zweite Zeile lädt den entsprechenden Treiber für die externe RTC auf dem RPi400extBrd. Die DS3232 ist kompatibel zur DS3231, hat aber zusätzlich noch 234 Bytes frei verwendbaren batteriegepufferten RAM-Speicher.

    Überprüfung mit
    ls -l /dev/rtc*

    Code
    lrwxrwxrwx 1 root root      4  4. Feb 22:11 /dev/rtc -> rtc0
    crw------- 1 root root 252, 0  4. Feb 22:11 /dev/rtc0
    5. I2S-Audio

    Hier ist der Witz, dass die I2S-Soundkarten in der dtoverlay-Zeile von /boot/firmware/config.txt als slave deklariert werden müssen:

    Code
    dtoverlay=hifiberry-dacplus,slave

    Dann muss nicht einmal mehr die ursprünglich vorhandene Audioeinstellung

    Code
    dtparam=audio=on

    auskommentiert werden.


    Im Desktop muss man jetzt rechts oben nur noch auf das Lautsprechersymbol rechtsklicken und die Soundkarte snd_rpi_hifiberry_dacplus als Default wählen, siehe Bild. Das System merkt sich diese Einstellung und die I2S-Soundkarte ist nach jedem Reboot ausgewählt.


    Und hier die /boot/firmware/config.txt:

    config.txt

    Hofei, das wollte ich gestern noch ergänzen, dann war aber die Mittagspause um. Die Fehlermeldungen von chkdisk kann ich bestätigen, denn ich habe mich vor längerer Zeit mal ausführlicher mit FAT12, 16, 32 beschäftigt.

    Das ändert aber nichts daran, dass dieses hier beschriebene ständige Hin und Her der RPi-Foundation zugunsten der Windows-Anwender wichtige(?) RPi-Skripte von RPi-Programmierern zunächst fehlerhaft werden lässt. Die haben auch was anderes zu tun, als ihre Skripte und Programme um notwendige Würgarounds abzuklopfen.

    Nach über 10 Jahren des "Massenphänomens" Raspberry Pi könnte aber auch Microsoft mal in die Gänge kommen und sein OS wenigstens so erweitern, dass es eine RPi-SD-Karte als eine solche mit zwei Partitionen erkennt, anstatt vorzuschlagen, sie neu (womöglich mit (dr)exFAT) zu formatieren.

    Wo steht das?

    Wo finde ich das offizielle chkdisk? Ich kenne nur fsck und da gibt es keine Fehlermeldungen :conf:

    Du kennst chkdisk nicht, weil Du (wie ich) ein ignoranter Linuxnerd bist und die wirklich wichtigen Betriebssysteme hartnäckig ignorierst!

    Aber im Ernst:
    Ist der RPi jetzt eine Linuxmaschine oder eine Windowsmaschine? Prinzipiell eigentlich beides, aber letzteres scheitert de facto, weil der RPi für ein darauf installiertes Windows einfach zu schwachbrüstig ist. Man kann natürlich auch einen Windows-PC nutzen, um mit dem RPi zu arbeiten, aber dann sollte es nicht zu viel verlangt sein, dass die Windowsnutzer die Besonderheiten (um das Wort Unzulänglichkeiten zu vermeiden) ihres Betriebssystems beachten. Zumal sie sich ja RPi-seitig ohnehin mit Linux beschäftigen müssen. :2cents:

    Wenn die Messprotokolle auf einer separaten Read/Write-Partition (z.B. eine von / getrennte home-Partition) oder sogar auf einem anderen Laufwerk gespeichert werden, kann man auch überlegen, das Dateisystem mit den Messprotokollen direkt nach dem Erstellen/Schreiben der Datei in einen stabilen Zustand zu bringen.
    Ich glaube, dass das Shellkommando sync so etwas macht. Aber grundsätzlich bin ich für kompetente Ratschläge hierzu ein zu wilder Linux-Dauernoob!

    Vielleicht so:
    /boot-Partition: readonly
    /-Partition: Overlay-Dateisystem
    /home-Partition: R/W, nach Schreibzugriffen erfolgt ein hart getriggerter sync

    Trotz Industrie-SD-Karten hatten wir Zwischenfälle, bei denen Daten beschädigt waren bzw. ganze SD-Karten zerstört waren. Deswegen wollen wir die Adapterplatine weiter nutzen.

    Ob Dateien auf der SD-Karte beim urplötzlichen Abschalten der Stromversorgung hinterher beschädigt sind, hat nichts mit der Qualität der SD-Karte (bzw. dem Speichermedium) zu tun, sondern ist eine systembedingte Sache: Sowohl um die Schreibzugriffe zu reduzieren als auch um die Geschwindigkeit zu erhöhen werden von den meisten modernen Betriebssystemen (sogar Windows) die Schreibzugriffe (Dateiänderungen) zunächst in einem Puffer (Cache) zwischengespeichert. Von Zeit zu Zeit oder spätestens beim geordneten Herunterfahren des Betriebssystems werden ausstehende Schreibzugriffe physikalisch auf's Laufwerk geschrieben.

    Ein plötzliches Abschalten der Stromversorgung macht ein solches System natürlich zunichte! Es mag sein, dass es 99 mal folgenlos bleibt, aber beim 100. Mal ist das Dateisystem "zerschossen".

    Falls mit plötzlichem Abschalten zu rechnen oder dies sogar gewollt ist, kann man mit einem ReadOnly-Dateisystem arbeiten oder der modernen Variante davon, einem Overlay-Dateisystem. Damit bleibt das Dateisystem immer konsistent. Der Nachteil ist, dass nach dem Abschalten immer der Stand der Dateien so vorliegt, wie er beim Erstellen des Overlay-Dateisystems war. Dateiänderungen gehen verloren.

    Oder eben eine Supercap-USV, die dem RPi-Betriebssystem ein sauberes Herunterfahren ermöglicht.

    Wenn's ein mechanisches Kontaktproblem am SD-Kartenslot ist ("ausgeleiert"), fällt mir noch folgende Idee ein:
    SD-Karte mit Tesafilm o. Ä. dicker machen, so dass es die Kontaktflächen der Karte stärker auf die Gegenpins des Slots drückt. Vielleicht kann so ein einigermaßen sauberer Kontakt hergestellt werden?
    Ebenso kann man vorher noch versuchen, den SD-Slot mit Kontaktspray zu reinigen...

    Viel Glück!

    EDIT:
    Kommt wenigstens das quadratische Regenbogenbild kurz nach dem Einschalten?

    Ich werfe mal in den Raum, dass das scheinbar unterschiedliche Verhalten print() und GPIO.output(<Pin-Nummer>, LOW) von daher rührt, dass die print-Ausgabe "fest" im Terminal angezeigt wird, auch nach dem Beenden, während bei (fehlendem) GPIO.output(...) der Python-Interpreter (bzw. die Python-Runtime) beim Programmende eine Art garbage collection macht und die Instanz der GPIO-Klasse eigenständig rücksetzt, sauber(?) beendet und aus dem RAM löscht. Dies führt dazu, dass die LED nach Programmende auch dann nicht weiterleuchtet.
    Vielleicht wird der GPIO-Pin sogar auf input umgestellt?

    Dies könnte man möglicherweise überprüfen, indem man in jeden except-, finally-, etc-Zweig ein Konstrukt à la

    Code
    finally:
        GPIO.output(<pin-Nummer>, LOW)
        time.sleep(0.5)
        GPIO.output(<pin-Nummer>, HIGH)
        time.sleep(0.5)
        GPIO.output(<pin-Nummer>, LOW) # Test mit dieser Zeile oder auch auskommentiert
        GPIO.cleanup()                 # Auch diese Zeile testweise auskommentieren

    schreibt und die LED beim Programmende beobachtet, was die LED macht.

    Wird der finally-Zweig durchlaufen, geht die LED für 0.5s aus, dann nochmals für 0.5s an und dann endet das Programm.

    Ohne finally-Zweig geht die LED ohne nachblinken aus.

    Oder am 12V(?)-Netzteil für den Amp2 parallel einen guten(!) Step-down-Regler für 5V/5A betreiben, dessen Ausgang du dann an den 5V-Pins des RPi5 anschließt. Das 12V-Netzteil muss natürlich genügend Ampere liefern (siehe oben).

    Servus pully,

    mit "auftrennen" der GPIOs meine ich die Verbindung zwischen dem RPi5 und dem Pi-HAT (hier dem Amp2) Dazu muss man an den 38 verbleibenden GIO-Pins 1:1-Verbindungen herstellen und die beiden 5V-Pins weglassen. Zu Testzwecken würde ich da mit einem 40-pol. Zwischen-Verbindungsstück beginnen, bei dem man die beiden 5V-Pins z.B. mit einem Seitenschneider durchzwickt. Oder 38 DuPont-/Jumperkabel verwenden.

    Vielleicht das Alte Pi Netzteil mit 2.5A so wärs zumindest nicht Zuviel ... ich versteh das Zusammenspiel mit USB-C Stromeingang und GPIO Stromeingang vom Aktiven Hat nicht wirklich...

    Versorgung über Netzteil:
    Problematisch ist nur die falsche (zu hohe) Spannung (Voltzahl)! Da kann etwas kaputt gehen.
    Der Stromfluss (Ampere) wird vom Verbraucher bestimmt. Hier muss das Natzteil nur die Fähigkeit haben, genügend zu liefern.
    Beim RPi5 mit 5A Stromfluss muss das Netzteil also mindestens 5A liefern. Es macht aber nichts, wenn es 6A oder 100A liefern könnte. Der RPi5 nimmt nur, was er wirklich braucht.

    Lineage OS ist ein googlefreies Android. Da kann ich mir gut vorstellen, dass dann gar keine Googledienste laufen, auch kein Google Playstore.

    Liegt bei diesen proprietären Dingen in der Natur der Sache. Das haben die Datenkraken dick, wenn die Lauschkanäle unerwartet zu sind...

    Danke Jürgen,

    Das ist jetzt saublöd, denn ein Interessent will das RPi400extBrd an einem RPi5 betreiben.

    Es wird für mich wohl kein Weg am RPi5 vorbei führen, obwohl ich den eigentlich nicht brauche und nicht will: Lüfter sag ich bloß... :fies:
    Was braucht man da gleich nochmal alles?

    PS:
    Welches OS nutzt Du (also Desktop oder lite)?
    Eintrag dtoverlay=hifiberry-dacplus ist schon in der config.txt eingetragen?
    --> ich meine mal, vor längerer Zeit meinen Original HifiBerry DAC+ ohne jeglichen Eintrag in der config.txt betrieben zu haben. Das lief wohl nur über das ID-EEPROM

    EDIT:
    Den Eintrag dtparam=i2s=on kenne ich gar nicht. Gibt's den schon länger? Möglicherweise ist der sogar kontraproduktiv. Ist aber nur ein Bauchgefühl...

    Ich denke schon, dass es möglich ist, den RPi5 nicht über den HiFiBerry Amp2 zu versorgen, sondern separat über die USB-C-Buchse.
    Dazu muss man -- Achtung: Unwort! -- nur die 5V-Power-Pins auf der GPIO-Leiste (Pins 2 und 4) zwischen RPi5 und Amp2 auftrennen. Die Masseverbindungen müssen dabei bestehen bleiben.
    Den RPi5 dann mit 5V über die USB-C-Buchse aus einer anderen Quelle versorgen, zu Testzwecken zunächst mit dem originalen 27W-Netzteil der RPi-Foundation.
    (Später dann ein vernünftiger Step-Down-Regler auf 5,1V/5A)

    Ich glaube, ich werde mir demnächst einen RPi5 kaufen müssen, schon alleine deshalb, um mein RPi400extBrd damit zu testen....
    EDIT 11.02.2024 -- erledigt:
    Spezielle Anpassungen bezüglich I2S-Soundkarten in der /boot/firmware/config.txt für den RPi5: siehe hier
    Die I2S-Soundkarte muss in der config.txt als slave desklariert werden:
    dtoverlay=hifiberry-dacplus,slave

    Bezüglich Raspberry Pi OS bookworm (mit Wayland) auf einem RPi4/RPi400 kann ich sagen, dass dies mit meinem Board (und damit höchstwahrscheinlich mit dem HiFiBerry DAC+ und allen davon abgeleiteten HiFiBerry-Derivaten) mit dem Eintrag dtoverlay=hifiberry-dacplus in der config.txt problemlos läuft.

    Evtl. dtparam=audio=on auskommentieren

    Servus headcrash

    willkommen im Forum!

    Netzteil:
    Ein "USB-C Ladegerät" ist kein Netzgerät zum Betrieb eines RPi, egal wieviel Watt es liefert. Das Mysterium™ lässt grüßen, denn ein Ladegerät ist nicht dafür ausgelegt, ständig eine konstante Spannung zu liefern. Hier kann es passieren, dass für ein paar Millisekunden die Spannung einbricht, was der RPi nicht verzeiht. Ein "echtes" Netzteil ist für einen unmysteriösen Betrieb unerlässlich. Bitte das originale Netzteil für den RPi5 verwenden!
    --> Ist Dein Originalnetzteil wirklich dieses?

    RDP vs. VNC:
    Ich habe gerade gelernt, dass TigerVNC für den Zugriff auf einen RPi mit Raspberry Pi OS bookworm, auf dem Wayland läuft (dürfte auf Deinem 5er der Fall sein), die bessere Alternative ist.

    EDIT:
    hyle war mal wieder schneller!