{"id":167,"date":"2017-05-28T01:25:49","date_gmt":"2017-05-27T23:25:49","guid":{"rendered":"https:\/\/www.pingu-mobil.de\/iot\/?p=167"},"modified":"2021-05-14T10:07:53","modified_gmt":"2021-05-14T08:07:53","slug":"anpassen-der-linux-bootparameter","status":"publish","type":"post","link":"https:\/\/www.iot-embedded.de\/iot-2017\/technik\/anpassen-der-linux-bootparameter\/","title":{"rendered":"Anpassen der Linux Bootparameter"},"content":{"rendered":"

Die nachfolgende Beschreibung ist aus einem neuen Kapitel im Skript, das ich eben hinzugef\u00fcgt habe. Neben diesem Kapitel enth\u00e4lt es noch weitere neue Kapitel zur Integration von Node.JS sowie grafischer Oberfl\u00e4chen in die mit Buildroot erstellte Firmware.<\/p>\n

\n

Dem Linux-Kernel k\u00f6nnen beim Starten verschiedene Parameter mitgegeben werden, um das Verhalten des Betriebssystems zu beeinflussen. Beispielsweise bekommt der Kernel oftmals den Namen der Root-Partition als Parameter \u00fcbergeben, damit er diese w\u00e4hrend dem Startvorgang mounten und somit nutzbar machen zu k\u00f6nnen. Wo die Parameter einzutragen sind h\u00e4ngt dabei von der jeweiligen Hardware-Plattform sowie dem verwendeten Boot-Loader ab. Im Falle des Rasperry Pi ist es aber ganz einfach. Dort befindet sich auf der ersten Partition der SD-Karte eine Datei namens cmdline.txt<\/code>. Sie enth\u00e4lt genau eine Zeile mit den an den Kernel zu \u00fcbergebenen Bootparametern.<\/p>\n

dennis@metropolis:\/run\/media\/dennis\/0FBE-CE26$ more cmdline.txt \nroot=\/dev\/mmcblk0p2 rootwait console=tty1 console=ttyAMA0,115200<\/pre>\n
Wie Sie sehen bekommt der Kernel hier folgende Parameter \u00fcbergeben:<\/p>\n\n\n\n<\/colgroup>\n\n\n\n\n\n
 
\n
root=\/dev\/mmcblk0p2<\/span><\/span><\/p>\n<\/td>\n
\n
Teilt dem Kernel mit, dass die zweite Partition (p2<\/span><\/code>) der SD-Karte (\/dev\/mmcblk<\/span><\/code>) das Dateisystem mit dem Root-Verzeichnis beinhaltet.<\/span><\/span><\/p>\n<\/td>\n<\/tr>\n
\n
rootwait<\/span><\/span><\/p>\n<\/td>\n
\n
Weist den Kernel an, beim Einh\u00e4ngen der Root-Partition ohne Timeout auf die SD-Karte zu warten.<\/span><\/span><\/p>\n<\/td>\n<\/tr>\n
\n
console=tty1<\/span><\/span><\/p>\n<\/td>\n
\n
Sorgt daf\u00fcr, dass alle Kernel-Meldungen auf der ersten virtuellen Konsole ausgegeben werden. Deshalb sehen Sie so viele Meldungen vorbeiziehen, w\u00e4hrend das System startet.<\/span><\/span><\/p>\n<\/td>\n<\/tr>\n
\n
console=ttyAMA0,115200<\/span><\/span><\/p>\n<\/td>\n
\n
Weist den Kernel an, seine Meldungen mit einer Baudrate von 115200 Bits \/ Sekunde auf dem Serial Port auszugeben. Diese M\u00f6glichkeit wird insbesondere von eingebetteten Systemen genutzt, um die Kernelmeldungen verf\u00fcgbar zu machen, ohne Sie auf dem Display des Ger\u00e4ts anzuzeigen.<\/span><\/span><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Eine gute \u00dcbersicht der m\u00f6glichen Kernel-Parameter finden Sie zum Beispiel auf redsymbol.net (http:\/\/redsymbol.net\/linux-kernel-boot-parameters\/)<\/a>. Ein weiterer n\u00fctzlicher Parameter k\u00f6nnte in diesem Zusammenhang auch quiet<\/code> sein. Durch ihn unterdr\u00fccken Sie s\u00e4mtliche Kernel-Meldungen bis auf wirklich schwerwiegende Fehler, wodurch das System auch ein wenig schneller startet. Um ihn zu erg\u00e4nzen, h\u00e4ngen Sie ihn einfach durch ein Leerzeichen getrennt an die Zeile in der cmdline.txt<\/code>-Datei an:<\/p>\n
dennis@metropolis:\/run\/media\/dennis\/0FBE-CE26$ more cmdline.txt \nroot=\/dev\/mmcblk0p2 rootwait console=tty1 console=ttyAMA0,115200 quiet<\/code><\/pre>\n
Allerdings hat dieses Vorgehen den Nachteil, dass die \u00c4nderung bei jeder Neuerstellung der Firmware verloren geht. Sie m\u00fcssten die \u00c4nderung daher jedes mal wiederholen, wenn Sie ein neues Firmeware-Image bauen und auf die SD-Karte schreiben. Nachfolgend soll daher gezeigt werden, wie Sie die \u00c4nderung in den Build-Prozess von Buildroot integrieren k\u00f6nnen. Leider ist dies etwas aufw\u00e4ndig, da hierf\u00fcr \u00fcberraschenderweise keine einfache M\u00f6glichkeit in Buildroot vorgesehen ist. Sehr schwer ist es aber nicht.<\/p>\n
Zun\u00e4chst m\u00fcssen Sie verstehen, wie nach dem Zusammenstellen des Wurzeldateisystems das finale Abbild der SD-Karte erzeugt wird. Hierf\u00fcr ist die folgende Konfigurationsoption zust\u00e4ndig:<\/p>\n
System configuration \u2192 Custom scripts to run after creating filesystem images<\/cite><\/p>\n
Wie Sie sehen, ist dort der Wert board\/raspberrypi3\/post-image.sh<\/code> voreingestellt, wobei sich der Pfad auf das Buildroot-Verzeichnis bezieht. Der vollst\u00e4ndige Pfad lautet daher ~\/buildroot\/board\/raspberrypi3\/post-image.sh<\/code>. Wenn Sie sich das Skript dabei anschauen, f\u00e4llt Ihnen am Ende des Skripts sicher folgender Befehl auf:<\/p>\n
genimage\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \\\n\u00a0\u00a0 \u00a0--rootpath \"${TARGET_DIR}\"\u00a0\u00a0\u00a0\u00a0 \\\n\u00a0\u00a0 \u00a0--tmppath \"${GENIMAGE_TMP}\"\u00a0\u00a0\u00a0 \\\n\u00a0\u00a0 \u00a0--inputpath \"${BINARIES_DIR}\"\u00a0 \\\n\u00a0\u00a0 \u00a0--outputpath \"${BINARIES_DIR}\" \\\n\u00a0\u00a0 \u00a0--config \"${GENIMAGE_CFG}\"<\/pre>\n
Dieser Befehl ist es, der die fertige sdcard.img<\/code>-Datei erzeugt. ${TARGET_DIR}<\/code> verweist dabei auf das Verzeichnis mit dem assemblierten Wurzeldateisystem (Partition 2 auf der SD-Karte). ${BINARIES_DIR}<\/code> hingegen ist das Verzeichnis, in dem die Dateien f\u00fcr die Boot-Partition abgelegt werden, indem sich auch die Datei cmdline.txt<\/code> befindet. Die Idee, um den Inhalt dieser Datei anzupassen, ist daher, ein eigenes Skript zu schreiben, das vor dem bereits hinterlegten Skript l\u00e4uft und die cmdline.txt<\/code> f\u00fcr uns anpasst.<\/p>\n
Legen Sie hierf\u00fcr im custom<\/code>-Verzeichnis eine neue Datei mit folgendem Inhalt an und sorgen Sie daf\u00fcr, dass die Datei ausf\u00fchrbar ist. Den genauen Inhalt m\u00fcssen Sie nat\u00fcrlich anpassen, je nachdem welche Bootparameter Sie an den Kernel \u00fcbergeben m\u00f6chten. Achten Sie beim Abschreiben auch auf die genaue Schreibweise und dabei insbesondere auf falsch platzierte Leerzeichen, da das Skript sonst nicht funktioniert.<\/p>\n
buildroot@debian:~\/custom$ nano cmdline.sh<\/pre>\n
#! \/bin\/sh\necho \">> F\u00fcge weitere Bootparameter in der cmdline.txt hinzu\"\n\n# Einlesen der Bootparameter aus cmdline.txt\nCMDLINE_TXT=\"$BINARIES_DIR\/rpi-firmware\/cmdline.txt\"\nBOOT_PARAMS=\"\"\n\nwhile read line; do\n\u00a0\u00a0\u00a0 if [ -z \"$BOOT_PARAMS\" ]; then\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 BOOT_PARAMS=\"$line\"\n\u00a0\u00a0\u00a0 else\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 BOOT_PARAMS=\"$BOOT_PARAMS $line\"\n\u00a0\u00a0\u00a0 fi\ndone < \"$CMDLINE_TXT\"\n\n# F\u00fcgen Sie hier nach Bedarf weitere Parameter hinzu\nBOOT_PARAMS=\"$BOOT_PARAMS quiet\"\n\n# Ver\u00e4nderten Inhalt in cmdline.txt schreiben\necho \"$BOOT_PARAMS\" > \"$CMDLINE_TXT\"<\/pre>\n
buildroot@debian:~\/custom$ chmod +x cmdline.sh<\/pre>\n
Anschlie\u00dfend starten Sie das Buildroot-Konfigurationsmen\u00fc und \u00e4ndern Sie folgenden Wert, damit das neue Skript aufgerufen wird:<\/p>\n
System configuration \u2192 Custom scripts to run after creating filesystem images:
\n<\/cite>$(BR2_EXTERNAL_DHBW_PATH)\/cmdline.sh board\/raspberrypi3\/post-image.sh<\/code><\/p>\n
Anschlie\u00dfend bauen Sie ein neues Firmware-Image. Wenn alles geklappt hat, beinhaltet die cmdline.txt<\/code> auf der ersten Partition nun die ver\u00e4nderten Bootparameter.<\/p>\n","protected":false},"excerpt":{"rendered":"
Die nachfolgende Beschreibung ist aus einem neuen Kapitel im Skript, das ich eben hinzugef\u00fcgt habe. Neben diesem Kapitel enth\u00e4lt es noch weitere neue Kapitel zur Integration von Node.JS sowie grafischer Oberfl\u00e4chen in die mit Buildroot erstellte Firmware. Dem Linux-Kernel k\u00f6nnen<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[6],"tags":[],"_links":{"self":[{"href":"https:\/\/www.iot-embedded.de\/iot-2017\/wp-json\/wp\/v2\/posts\/167"}],"collection":[{"href":"https:\/\/www.iot-embedded.de\/iot-2017\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.iot-embedded.de\/iot-2017\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.iot-embedded.de\/iot-2017\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.iot-embedded.de\/iot-2017\/wp-json\/wp\/v2\/comments?post=167"}],"version-history":[{"count":1,"href":"https:\/\/www.iot-embedded.de\/iot-2017\/wp-json\/wp\/v2\/posts\/167\/revisions"}],"predecessor-version":[{"id":590,"href":"https:\/\/www.iot-embedded.de\/iot-2017\/wp-json\/wp\/v2\/posts\/167\/revisions\/590"}],"wp:attachment":[{"href":"https:\/\/www.iot-embedded.de\/iot-2017\/wp-json\/wp\/v2\/media?parent=167"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.iot-embedded.de\/iot-2017\/wp-json\/wp\/v2\/categories?post=167"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.iot-embedded.de\/iot-2017\/wp-json\/wp\/v2\/tags?post=167"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}