Display MoreMoin Rick00,
hast du dir das schon mal durchgelesen?
https://www.raspberrypi.org/do…uters/compute-module.html
Sieht nach einer Installationsanleitung aus.
73 de Bernd
Ja, die offizielle Doku ist mir bekannt, bietet aber in dieser Hinsicht keine Infos.
Zumindest hab ich nix gefunden.
Irgendwie verstehe ich nicht, warum du den bootloader updaten willst, bzw. was du damit erreichen willst.
z.B NVMe booting via PCIe. Nur möglich mit dem aktuellstem Bootloader.
--> Siehe hier
Hallo Bernd!
Keine Ahnung welchen CM4 du hast. Mit SD-Karte oder eMMC.
CM4 Lite 8GB RAM, WLAN gestern gekommen...
Nein, die SSD sollte schon als ein ext4-Laufwerk eingerichtet sein. Das kannst du mit einem Linuxrechner machen oder mit einem RPi.
Wichtig ist nur das die PARTUUID der SSD in der /boot/cmdline.txt steht.
In der Anleitung legt er 1ne Partition an und formatiert diese mit ext4.
Dort legt er einen Ordner (rootFSMigration) an. Normalerweise ist rootfs ja ne eigene Partition, oder?
Und kopiert die rootfs von der SD-Card in das Verzeichnis.
Aber in der neu angelegten Partition auf der SSD ist ja kein OS drauf. Also was will er dann booten?
Was bedeutet eigentlich rootfs = root file system?
Was die rootfs Partition genau ist, hab ich auch noch nicht kapiert bzw. keine einfach zu verstehende Beschreibung gefunden.
Gruß
Rick
Hallo!
HW:
Ich versuche schon seit einiger Zeit zu verstehen, wie man beim CM4 Lite ohne eMMC-Speicher in Kombi mit dem I/O-Board ein Bootloader-Update hinbekommt.
Ich bin echt schon am verzweifeln. 
In allen Dokus, die ich bisher gefunden und gelesen habe wird immer nur vom eMMC-Speicher gesprochen. Vom Lite Modul mit uSD-Card kein Wort 
Compute Module 4 Bootloader (Raspi Doku):
The Compute Module 4 ROM never runs recovery.bin from SD/EMMC and the rpi-eeprom-update service is not enabled by default.
This can be overridden and used with self-update mode where the bootloader can be updated from USB MSD or Network boot. However, self-update mode is not an atomic update and therefore not safe in the event of a power failure whilst the EEPROM was being updated.
Flashing the bootloader EEPROM - Compute Module 4:
To flash the bootloader EEPROM follow the same hardware setup as for flashing the EMMC but also ensure EEPROM_nWP is NOT pulled low
-> Steps to Flash the eMMC (Doku)
-> Flashing the Compute Module eMMC (github)
->Full Compute Module 4 (Raspberry Pi) Setup / Imaging Guide (James Chambers)
Ist bei einem CM Lite die SD-Card im Prinzip das Gleiche wie der eMMC-Flash und somit in der Doku eMMC mit SD-Card zu ersetzen?
Muß ich mir als Windows-User erst mal einen Pi aufsetzten um damit die Linux-Anweisungen ausführen zu können?
Manno, da hab ich mir wieder mal was eingebrockt 
ThanX
Rick
- Moin Rick00,
Es ist auf jeden Fall nicht einfach. Der Kernel muss mit Sata-Daten neu kompeliert werden und auch sonst ist einiges zu beachten.
Am Besten hat wohl eine Karte mit einem AsMedia ASM1061 abgeschnitten.
Hallo Bernd,
danke für den Link.
Ich habe mir den PCIe-SATA Adapter mit ASM1064 Chip bestellt (Syba/IOCrest ASM1064 PCIe SATA 4-port Controller) da ist der Treiber bereits im aktuellen Kernel enthalten.
Zitat von Jeff Geerling:
Since mid-2021, SATA support is built into the Raspberry Pi kernel, so assuming you have updated to the latest version (sudo apt upgrade -y), this card should work out of the box.
Auf meine Frage bez. Workaround zum Booten von SATA-Devices via PCIe-Card hab ich folgende Antwort erhalten:
Quoteyou boot from small (even 128MB is enough) microsd or usb stick with just /boot partition and point it to root filesystem on sata ssd. You may also need right sata driver modules for your specific sata chip in initrd if linux kernel does not have it built in.
Das ist doch das selbe Vorgehen, wie beim "alten" USB-Boot-Workaround mit SD-Card, bevor das Bootloader-Update kam, oder?
Diesbezüglich hab ich im selben Forum noch einen Workaround gefunden, den ich aber leider nicht richtig verstehe, vielleicht könnt Ihr mir weiterhelfen?:
HOWTO: Move the rootfs to native SATA (no usb adapter
1.) You need to ensure the SATA drivers are built-in to the kernel and not built as modules.
Da der Treiber für meine Karte im Kernel enthalten ist, brauch ich da nix machen.
2.) Erstellung einer einzelnen Partition auf der SSD mit fdisk und anschl. Formatierung
3.) Mounten der neu erstellten Partition
4.) Kopieren von rootfs von der SD-Card auf die SSD
5.) Modifikation der Boot-Config: Sicherungskopie erstellen + Root-Eintrag ändern (PARTUUID)
6.) Modifizierung der fstab auf der SSD um die Partition zu mounten + ändern des Root-Eintrags auf die neue Root-Partitions-ID (PARTUUID)
Was will er denn dann booten, da ist doch noch gar kein Image (OS) auf der SSD vorhanden. Wie bekommt er denn dann das noch rauf?
Mit etcher geht das dann nicht mehr weil dann ist die ganze Partition mit rootfs wieder futsch.
Kopiert er das dann noch von der SD-Card auf die SSD?
Ist es da nicht einfacher, wenn man zuerst auf SD-Card und SSD das gleiche Image mit etcher schreibt?
Grüße
Rick
Hallo Bernd,
danke für den Tipp - meinst den Artikel?
Hast Du zufällig die Ausgabe? Steht da wirklich was brauchbares drinnen. Will jetzt nicht knapp 6 Euro in die Tonne kloppen....
Gruß Rick
Hallo!
An dem Thema denke ich schon ne Weile herum.
Da ich ne UVS für mein eigenbau NAS brauche, wo ich auch eine 3,5 Zoll HDD verbauen möchte und somit auch 12V benötige ist das Thema etwas aufwändiger.
Mein Ansatz in der Reihenfolge von 230V zu Stromversorgung RPi4+Hardware:
- 24V Schaltnetzteil z.B MeanWell)
- Step-Down-Modul mit Strombegrenzung als Laderegler für den Akku
- 12V Bleiakku
- StepUp+StepDown (SEPIC) Modul für 12V
- StepDown-Modul für 5V
Der Bleiakku funktioniert quasi als großer "Elko" / Puffer.
Fällt der Strom aus, so versorgt die Batterie ohne Unterbrechung den RPi + Hardware.
Die gesamte USV ist aus fertigen Modulen zusammengestellt, die nur noch "verbunden" werden müssen.
Da ist jetzt natürlich noch keine intelligente Überwachung dabei, welche die Akkuspannung erfasst und den RPi mitteilt, er solle herunterfahren, wenn der Akku leer wird. Dazu bräuchte man dann noch einen Arduino.
Leider hab ich bisjer keine Ahnung wie man auf möglichst einfachen Weg eine Kommunikation zw. Arduino und RPi herstellt und dann auch die Infos am RPi verarbeitet.
Edit: Der einfachste Weg ist sicherleich der, einen Pin am Arduino von hi auf low zu schalten wenn eine definierte Betteriespg. unterschritten wird.
Den Zustand am RPi auswerten. Wenn low -> RPi runterfahren.
Nicht zwingend, oder? Ich nehme an, das der Boot-Loader schon aktuell sein kann. Zumindest würde ich davon ausgehen, dass wenn ich ein neuen RPi 4(00) kaufe, das dieser aktuell daher kommt.
Ich habe meinen RPi4 2019 gekauft und ihn bisher nicht benutzt.
Habe bisher nur Bootversuche mit USB-SATA-Adapter gemacht und Raspberry Pi OS (lite+full) von der SD-Card gebootet
+ Install OMV5 lt. Anltg. Wiki:
Before installing OMV, update and upgrade Raspberry PI OS using the following commands, executed one at at time:
sudo apt-get update
sudo apt-get upgrade -y
sudo rm -f /etc/systemd/network/99-default.link
Habe bisher also kein manuelles Bootloader-Update gemacht. Trotzdem ist mein Bootloader aktuell.
Wie kann das sein? Wird da einfach automatisch ein Update im Hintergrund gemacht, wenn man ein aktuelles RPi OS bootet bzw. neu installiert?
Hallo!
Ich bin auf der Suche nach einer PCIe-SATA Karte die problemlos mit dem CM4+I/O-Board funktioniert.
Bisher bin ich nur auf die Liste von Jeff Geerling gestoßen.
Dort sind im Prinzip "nur" 3 Karten gelistet, welche problemlos funktionieren:
IO Crest 4 Port SATA III PCIe x1 with Marvell 9215
IOCrest JMB585 PCIe Gen3 SATA Controller
Syba/IOCrest ASM1064 PCIe SATA 4-port Controller
Gefunden hab ich bisher nur die 3te Karte bei Amazon.de. Die Links von Jeff für den Bezug der Karten sind alle von Amazon.com (USA).
Welche Erfahrungen habt ihr bisher gemacht?
Reicht es aus, wenn die Karte den beschriebenen Chipsatz hat um problemlos zu funktionieren, oder muß es wirklich genau die selbe Karte sein?
Kennt Ihr zufällich noch alternative Bezugsquellen aus dem EU-Raum?
Nachtrag Boot-Möglichkeit:
Nun habe ich leider auf der Seite von Jeff Geerling im Artikel: "Raspberry Pi OS now has SATA support built-in" gelesen, daß es aktuell keine direkte Möglichkeit gibt von SATA-Devices zu Booten.
Zitat:
One thing you can't do yet is boot the Pi from a SATA drive. You can boot from USB, microSD, eMMC, or even NVMe on the latest Pi OS, but currently the Raspberry Pi bootloader doesn't scan SATA devices for booting. At least not yet.
Jetzt hab ich im englischen RPi-Forum recherchiert und folgenden aktuellen HowTo-Artikel eines Users gefunden, um ein dirketes Booten von SATA-Devices via PCIe-Card zu ermöglichen:
HOWTO: Move the rootfs to native SATA (no usb adapter)
Leider übersteigt dies meine derzeitigen Linux/RPi Fähigkeiten und ich würde hierbei eure Hilfe benötigen.
Gruß
Rick
Hallo Rick00,
willkommen im Forum!
Danke!
Jain, das aber ist nur der Fall bei einem KernelUpdate. Trotzdem sehe ich auch keinen Vorteil, zusätzlich noch eine SD-Karte zu verwenden. Schon garnicht, bei einem 24/7 laufendem System wie ein NAS.
Ich leite davon mal ab, daß man bei einem "produktiven System" (wie einem NAS) die automatischen Updates deaktivieren sollte.
Was vielleicht noch sinnvoll sein kann, wäre die SD Karte als (Not?) Backup Medium zu nutzen. Nicht unbedingt die sicherste Methode, aber der Zugriff darauf wäre recht schnell.
Meinst Du damit die PArtition mit dem Betriebssystem von der SSD auf die SD-Card spiegeln und wenn es Probleme gibt die Bootreihenfolge ändern und von der SD-Card Booten?
Gibt es da dann nicht Probleme mit OMV, weil sich die Pfade geändert haben?
Was ich nicht ganz verstehe ist, daß wenn USB-Boot von der SSD ohne Einschränkungen einfach umsetzbar ist, in dem Beitrag "[Tutorial] Eine unendliche Geschichte: Raspberry 4B und USB-Boot" die Variane mit der SD-Card durchexerziert wird, ohne gleich am Anfang darauf hinzuweisen, daß dies alles nicht mehr benötigt wird, seit dem Boot-Loader-Update.
Übersehe ich da was?
Gruß
Rick
Hallo Dead_Eye!
Danke für den Link, den hätt ich gebraucht, bevor ich die große OP bei meinem RPi4 B gemacht habe. 
Das müßte wirklich funktionieren. Einfach D2 entfernen und auf die Funktion der roten LED pfeiffen. Somit wird der BCM4345 nicht mehr mit Spg. versorgt. Leider ist die Position von D2 bei dem Link nicht abgebildet.
Das ganze funktionert dann aber nur für den RPi4 B, nicht für das CM4.
CM4 + I/O-Bord:
Zum I/O-Bord hab ich folgendes im Datenblatt gefunden:
Jumper J3 auf dem I/O-Bord:
Zum CM4 Modul folgendes im Datenblatt:
2.1.1. WL_nDisable
When driven or tied low it prevents the wireles network module from powering up. This is useful to reduce power
consumption or in applications where it is required to physically ensure the wireless networking is disabled.
2.1.2. BT_nDisable
When driven, or tied low, it prevents the Bluetooth module from powering up. This is useful to reduce power
consumption, or in applications where it is required to physically ensure the Bluetooth is disabled.
Hört sich doch gut an. Somit sollte wirklich ganz einfach per Jumper WLAN+BT komplett deaktivierbar sein.
Grüße
Rick
Hallo!
Das Messgerät war ich selbst. Mußt Du jetzt natürlich nicht glauben. Aber mir ist es trotz der softwareseitigen Deaktivierung richtig dreckig gegangen.
Da kann man jetzt natürlich eineige Gegenargumente bringen, weil ich nicht physikalisch gemessen hab. Angefangen von nicht richtig deaktiviert bis eingebildet.
Habs auch mit rfkill probiert. Und lt. Doku müßte dann Schluß sein mit der funkerei.
The rfkill subsystem provides a generic interface for disabling any radio
transmitter in the system. When a transmitter is blocked, it shall not
radiate any power.Fakt ist, ohne IC hab ich keine Probleme.
Da ich jetzt keinen RPi mit WLAN-Chip zu Hause habe, kann ich auch keine Messungen machen, ob man den IC doch softwareseitig deaktivieren könnte....
Ich will mir aber auch kein CM kaufen und dann drauf kommen, daß es nicht geht und es somit nicht benutzen kann.
Gruß
Rick
Hallo!
Da ich überhaupt kein WLAN vertrage, bin ich auf der Suche nach einem CM4 Lite mit 4GB RAM ohne WLAN+BT. Leider sind (derzeit) nur CM4-Module mit 8GB RAM + eMMC verfügbar.
Habe nur 1 Lite-Modul mit 4GB RAM gefunden, daß allerdings WLAN hat.
Nun habe ich in der Beschreibung gelesen, daß es beim I/O-Bord jeweils 1nen Jumper zum Deaktivieren von WLAN bzw. BT gibt.
Weiß jemand zufällig ob beim Setzen des Jumpers der WLAN-Chip wirklich komplett deaktiviert wird und nicht, so wie es beim softwareseitigen deaktivieren leider der Fall ist, der WLAN-Chip munter weiter vor sich hinsendet.
Hab bei meinem RPi4 B bereits erfolglos versucht WLAN+BT per Befehl komplett zu deaktivieren. Mußte den kompletten IC entfernen, was bei meiner Ausrüstung fast unmöglich war/ist ohne den Pi zu zerstören. Aber jetzt is Ruhe!
Bluetooth und WLAN am Raspi abschalten
Gruß
Rick
Hallo!
Als RPi Neuling bin ich gerade dabei meine ersten Schritte mit meinem RPi4B zu machen, um mir ein kleines Eigenbau-NAS zu basteln.
Hierfür möchte ich OMV5 verwenden.
Zum Einsatz sollen eine SSD als Systemlaufwerk (für OMV5) und eine 3,5 Zoll HDD als Speichermedium kommen.
Eine SD-Card soll wenn überhaupt nur für sporatische Schreibzugriffe bzw. als RO verwendet werden.
Jetzt habe ich z.B. hier eine Anleitung gefunden, wo die SD-Card als Booterkennung (=Bootpartition?) verwendet wird.
Die meisten älteren USB-Boot-Anleitungen, bevor der RPi4 ein Update des Bootloaders bekommen hat, sind hier quasi lt. meinem derzeitigen Wissensstand indentisch.
Als Begründung warum die SD-Card weiterhin Anwendung findet:
QuoteDer Vorteil hierbei liegt auf der Hand. Da die SD-Card nur noch zum „Lesen“ der Booterkennung verwendet wird, muss man sich eigentlich keine Gedanken mehr machen, dass diese irgendwann ausgetauscht werden muss. Und das Backup der SSD sollte ab jetzt auch ein Kinderspiel sein, da man diese einfach am USB abziehen kann und am Rechner das Backup erledigt oder man verwendet einfach rsync am Raspi. Da muss man einfach nicht mehr auf die Bootpartition achten, da diese getrennt auf der SD-Card liegt. Weltklasse
Kann mir bitte jemand erklären, warum man besonders auf die Bootpartition achten muß, wenn man die SD-Card komplett weglässt und sich diese auf der SSD befindet?
Wird die Bootpartition eventuelle bei Updates überschrieben?
ThanX!
Grüße
Rick