OpenEmbedded-Entwicklungsumgebung

Aus Labor für Echtzeitsysteme

(Unterschied zwischen Versionen)
Wechseln zu: Navigation, Suche
Version vom 13:14, 30. Jun. 2009 (bearbeiten)
Maxkrickl (Diskussion | Beiträge)
K (Patches einpflegen)
← Zum vorherigen Versionsunterschied
Version vom 13:25, 30. Jun. 2009 (bearbeiten) (rückgängig)
Maxkrickl (Diskussion | Beiträge)
(Patches einpflegen)
Zum nächsten Versionsunterschied →
Zeile 237: Zeile 237:
= Patches einpflegen = = Patches einpflegen =
 +Es ist möglich, dass eigene Patches bereitgestellt werden müssen.
 +Diese Patches werden in dem Verzeichnis des Rezepts abgelegt, z. B. ${GUMSTIXTOP}/user.collection/package/linux/gumstix-kernel-2.6.21.
 +Um BitBake zu veranlassen, diesen Patch auch einzuspielen, wird ein Zeile in dem Rezept eingefügt.
 +${GUMSTIXTOP}/user.collection/package/linux/gumstix-kernel_2.6.21.bb
 +<pre>
 +...
 ++ file://sumversion.c.patch;patch=1 \
 +...
 +</pre>
 +
 +
 +Manchmal ist es auch nötig eine neue Datei hinzuzufügen.
 +Dazu geht man ähnlich vor wie bei den Patches:
 +* Datei hinterlegen
 +* Zeile zum Rezept hinzufügen (Allerdings ohne ";patch=1")
 +
 +<pre>
 +...
 ++ file://pni11096.c \
 +...
 +do_configure_prepend() {
 +...
 ++ cp ${WORKDIR}/pni11096.c ${S}/drivers/spi/
 +...
 +</pre>
= Links = = Links =

Version vom 13:25, 30. Jun. 2009

Inhaltsverzeichnis

Allgemeines

Während die Systemsoftware der ersten Gumstix-Rechner noch mit buildroot gebaut wurde, setzt Gumstix jetzt für die Systemsoftware auf OpenEmbedded. In OpenEmbedded sind verschiedene Targets definiert, wobei das Standard-Target gumstix-basic-image ist. Damit wird sowohl ein Kernel als auch das zugehörige Rootfilesystem für das eingebaute Flash erzeugt. Die Verwendung einer Ramdisk ist von Seiten Gumstix bisher nicht vorgesehen, auch wenn das zweifelsohne sinnvoll ist.

Fertige Images können von der Gumstix-OpenEmbedded-Website heruntergeladen werden:


Installation von OpenEmbedded

Die Anleitung zur Installation stellt die Seite [1] bereit.

Umgebungsvariablen setzen

Mittels

cat gumstix-oe/extras/profile >> ~/.bashrc

werden folgende Umgebungsvariablen gesetzt:

GUMSTIXTOP="${HOME}/gumstix/gumstix-oe"
OEBRANCH="${GUMSTIXTOP}/org.openembedded.snapshot"
GUMSTIXBRANCH="${GUMSTIXTOP}/com.gumstix.collection"
USERBRANCH="${GUMSTIXTOP}/user.collection"
PATH="${GUMSTIXTOP}/bitbake/bin:$PATH"
BBPATH="${GUMSTIXTOP}/build:${USERBRANCH}:${GUMSTIXBRANCH}:${OEBRANCH}"

Grundkonfiguration

In der Regel muss hier nichts verändert werden. Sollte es nicht möglich sein, die Berechtigungen für /usr/share/sources zu ändern, kann der Pfad in site.conf entsprechend angepasst werden. Das Quellenverzeichnis sollte jedoch nicht unbedingt auf das Homeverzeichnis gemappt werden, da - je nach Konfiguration - die Quellen gerne > 1GB sein könnten.

build/conf/site.conf
	DLDIR : Wohin die Quellen bei Download zwischengespeichert werden, i.d.Regel /usr/share/sources
	BBFILES : In welchen Verzeichnissen soll nach Pakten gesucht werden, default:
                  BBFILES="${OEBRANCH}/packages/*/*.bb ${GUMSTIXBRANCH}/packages/*/*.bb   ${USERBRANCH}/packages/*/*.bb"
	BBFILE_PRIORITY_oe="5"
	BBFILE_PRIORITY_gumstix="10"
	BBFILE_PRIORITY_user="15"

	PARALLEL_MAKE = "-j 4"
	BB_NUMBER_THREADS = "4"

build/conf/local.conf
	DISTRO_TYPE = " [release | debug]
	ANGSTROM_MODE = "[uclibc | glibc ]"

build/conf/auto.conf
	MACHINE = "gumstix-custom-verdex"

bitbake/conf/bitbake.conf
	FILESPATH
	P, PN, PR, PF
	TMPDIR
	WORKDIR

com.gumstix.collection/conf/machine/gumstix-custom-verdex.conf
  Use this file as a starting point for your custom gumstix configuration
  Edit it to reflect your hardware setup and then save it a parallel location in user.collection

	MACHINE_FEATURES
	kernel-module autoloading

Als nächstes holen wir uns vom svn unseren vorgefertigten userbranch:

svn co http://ezs.kr.hsnr.de/flobby/svn/gumstix/ <zielverzeichnis>

Unter <zielverzeichnis>/trunk/ findet sich nun das Archiv user.collection.tar.gz, das wir in unser GUMSTIXTOP-Verzeichnis entpacken

Rudimentäre Anpassungen, wie zum Beispiel die Netzwerkkonfiguration, zu ladende Module, zu mountende Dateisysteme, und eigene Init-Skripte können unterhalb des Verzeichnisses user_config innerhalb von user.collection getätigt werden.

Während in der Datei user_config/etc/init.d/S99xpostinit der Pfad zu einem Init-Skript (, dass sich auf der MMC-Karte befindet,) angegeben wird, wird in der Datei user_config/etc/init.d/S99xaddinit die Shell-Befehle direkt eingetragen.

Die Datei user_config/device_table enthält die device-nodes, die beim Generieren des Dateisystems erzeugt werden. Auch hier können Anpassungen vorgenommen werden.

Mittels
bitbake gumstix-custom-image
wird nun unser Kernel- und Dateisystemimage gebaut.

Das Kernelimage findet sich unter $GUMSTIXTOP/tmp/deploy/glibc/images/uImage-{VERSION}.bin. Das Dateisystem-Image findet sich unter $GUMSTIXTOP/tmp/ramdisk.img .

Beide Dateien können nun auf eine MMC kopiert werden und somit einem geeigneten U-Boot-Skript gebootet werden.

That's it

Generieren des Systems

Generieren von Root-Filesystem und Kernel

(Hinweis: das Setzen der Umgebungsvariablen kann auch wie oben mittels cat gumstix-oe/extras/profile >> ~/.bashrc geschehen

quade@shuttle:/tmp/gumstix/gumstix-oe>export GUMSTIXTOP="/tmp/gumstix/gumstix-oe"
quade@shuttle:/tmp/gumstix/gumstix-oe>export OEBRANCH="${GUMSTIXTOP}/org.openembedded.snapshot"
quade@shuttle:/tmp/gumstix/gumstix-oe>export GUMSTIXBRANCH="${GUMSTIXTOP}/com.gumstix.collection"
quade@shuttle:/tmp/gumstix/gumstix-oe>export USERBRANCH="${GUMSTIXTOP}/user.collection"
quade@shuttle:/tmp/gumstix/gumstix-oe>export PATH="${GUMSTIXTOP}/bitbake/bin:$PATH"
quade@shuttle:/tmp/gumstix/gumstix-oe>export BBPATH="${GUMSTIXTOP}/build:${USERBRANCH}:${GUMSTIXBRANCH}:${OEBRANCH}"
quade@shuttle:/tmp/gumstix/gumstix-oe>umask 0002
quade@shuttle:/tmp/gumstix/gumstix-oe>bitbake gumstix-basic-image

Generieren des Kernels

quade@shuttle:/tmp/gumstix/gumstix-oe>bitbake virtual/kernel -c clean
quade@shuttle:/tmp/gumstix/gumstix-oe>bitbake virtual/kernel

Benutzerdefinierte Konfigurationen

Benutzerdefinierte Branches (Parsetrees)

In der Datei ${GUMSTIXTOP}/build/conf/site.conf kann ein eigener Branch konfiguriert werden:

BBFILES="${OEBRANCH}/packages/*/*.bb ${GUMSTIXBRANCH}/packages/*/*.bb ${USERBRANCH}/packages/*/*.bb"
 
BBFILE_COLLECTIONS="oe gumstix user"
 
BBFILE_PATTERN_oe="^${OEBRANCH}/packages"
BBFILE_PATTERN_gumstix="^${GUMSTIXBRANCH}/packages"
BBFILE_PATTERN_user="^${USERBRANCH}/packages"
 
BBFILE_PRIORITY_oe="5"
BBFILE_PRIORITY_gumstix="10"
BBFILE_PRIORITY_user="15"
BBFILES beschreibt das Pattern, nach dem nach *.bb-Dateien gesucht werden soll.
BBFILE_COLLECTIONS definiert eigene Branches
BBFILE_PATTERN_<parsetree> definiert den Pfad zu den Paketen des Parsetrees
BBFILE_PRIORITY gibt die Priorität des Parsens an. Höhere Werte entsprechen höheren Prioritäten

${USERBRANCH) wird - wie oben beschrieben - in der .bashrc gesetzt

Generell können jedoch weitere Branches erzeugt werden, die niederpriore Branches überschreiben.

Eigenes Image erstellen

Ein user-image findet sich unter user.collection/packages/images/gumstix-user-image.bb Hier können eigene Softwarepakete hinzugefügt werden.

Das Image gumstix-custom-image vererbt alle Einstellungen, die hier vorgenommen werden.

Mit IMAGE_INSTALL += kann man die Pakete angeben, die mit installiert werden sollen.

Jedoch muss immer
bitbake gumstix-custom-image
aufgerufen werden, da hier die Ramdisk gebaut wird.

Root-Filesystem

Beim Booten wird das Programm /sbin/init gestartet. Die zu init gehörende Dokumentation findet sich unter /etc/inittab.

In der Standard-Inittab ist der Runlevel (default=5) eingetragen. Damit werden als erstes die Skripte im Verzeichnis /etc/rcS.d, danach die Skripte unter /etc/rc5.d abgearbeitet.

Die Skripte unter /etc/rcS.d im einzelnen:

S01keymap
Falls sich unter /etc/keymap... ein Tastaturlayout liegt, wird dieses per loadkeys geladen.
S02banner
Gibt anscheinend nur die Meldung booting... auf /dev/tty aus.
S03sysfs
Mounted procfs und sysfs.
S03udev
Komplexeres Skript um udevd zu starten.
S05devices
Erzeugt die Gerätedateien.
S06alignment
Setzt das Alignment auf 2.
S10checkroot.sh
Überprüft die Konsistenz des Root-Filesystems.
S20modutils.sh
Falls die Datei /etc/modules existiert, werden die darin gelisteten Treiber geladen. Zuvor wird noch depmod -Ae aufgerufen.
S30ramdisk
Mountet eventuell konfigurierte Ramdisks.
S35mountall.sh
Mountet alle (bisher nicht gemountete) Filesysteme.
S37populate-volatile.sh
Erzeugt die virtuellen Dateisysteme (tmpfs) für tmp und var.
S38devpts.sh
Mounted /dev/pts.
S39hostname.sh
Setzt nur den Hostname (sehr kurz).
S40networking
Startet das Netzwerk (inklusive dhcp) gemäß Konfiguration unter /etc/networking/interfaces.
S45mountnfs.sh
Mountet NFS- und Samba-Shares.
S55bootmisc.sh
Setzen von Zugriffsrechten, Anpassen von /etc/motd, ldconfig.
S98configure
Konfiguriert über das Paketmanagement (IPK) noch einmal die Pakete. Dabei wird unter anderem auch das Skript modutils.sh ein zweites Mal aufgerufen. De facto sorgt dieses Skript damit dafür, dass eine Menge Treiber geladen werden.
S99finish
Erstellt die Datei /etc/.configured.


Booten mit initialer Ramdisk

Der Kernel ist bereits für eine initiale Ramdisk vorkonfiguriert; es muss also prinzipiell nur noch die Ramdisk zur Verfügung gestellt werden. Theoretisch ist dazu nur das Image in ein komprimiertes CPIO-Archiv zu packen und dieses ist dann vom Bootloader dem Kernel zu übergeben. Praktisch ist der Bootloader U-Boot dafür auch ausgerichetet, aber einzelne Skripte und Treiber scheinen aus noch nicht ersichtlichen Gründen nicht zu funktionieren.

Da U-Boot leider noch nicht richtig mit der Netzwerkkarte zurecht kommt, sind kurze Entwicklungszeiten zur Zeit nur mit Hilfe einer SD-Karte möglich. Beim Booten überprüft U-Boot, ob eine SD-Karte vorhanden ist und ob auf der SD-Karte sich die Datei gumstix-factory.script befindet. Wird eine solche Datei gefunden, führt U-Boot die darin befindlichen Kommandos aus. Das Skript hat beispielsweise folgenden Inhalt:

# u-boot script
# tests for mmc card presence to determine if booting from mmc or cf
# so we can set the command line accordingly.
# the command line is used by initramfs' /init script to load the
# correct set of modules# if neither mmc or cf exist, then boot the flash file system from jffs2

if mmcinit; then
        setenv bootargs rw console=ttyS0,115200n8 reboot=cold,hard MEDIA=MMC
        fatload mmc 0 a1000000 uImage; && fatload mmc 0 a2000000 ramdisk.img
else
        if pinit on; then
                setenv bootargs rw console=ttyS0,115200n8 reboot=cold,hard MEDIA=CF
                fatload ide 0 a1000000 uImage; && fatload ide 0 a2000000 ramdisk.img
        else
                setenv bootargs root=1f01 rootfstype=jffs2 console=ttyS0,115200n8 reboot=cold,hard
                fsload && bootm
        fi
fi

bootm a1000000 a2000000

Aus dem Skript ist erkennbar, dass sich auf der SD-Karte der Kernel unter dem Namen uImage befinden muss und das Root-Filesystem (als gepacktes und mit mkinitram modifizierte CPIO-Archiv) unter dem Namen ramdisk.img. Das Skript selbst wird mit folgendem Befehl für U-Boot vorbereitet:

$GUMSTIXTOP/tmp/staging/i686-linux/bin/mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n gumstix-factory.script -d my-gumstix-factory.script gumstix-factory.script

Beim Generieren legth OpenEmbedded im Verzeichnis deploy die folgenden Dateien ab:

quade@shuttle:/tmp/gumstix/gumstix-oe/tmp/deploy/glibc/images/gumstix-custom-verdex>ls
Angstrom-gumstix-basic-image-glibc-ipk-2007.9-test-20080303-gumstix-custom-verdex.rootfs.jffs2
Angstrom-gumstix-basic-image-glibc-ipk-2007.9-test-20080303-gumstix-custom-verdex.rootfs.tar.gz
Angstrom-gumstix-basic-image-glibc-ipk-2007.9-test-20080304-gumstix-custom-verdex.rootfs.jffs2
Angstrom-gumstix-basic-image-glibc-ipk-2007.9-test-20080304-gumstix-custom-verdex.rootfs.tar.gz
Angstrom-gumstix-basic-image-glibc-ipk-2007.9-test-20080305-gumstix-custom-verdex.rootfs.jffs2
Angstrom-gumstix-basic-image-glibc-ipk-2007.9-test-20080305-gumstix-custom-verdex.rootfs.tar.gz
gumstix-basic-image-gumstix-custom-verdex.jffs2
gumstix-basic-image-gumstix-custom-verdex.tar.gz
modules-2.6.21-r1-gumstix-custom-verdex.tgz
uImage-2.6.21-r1-gumstix-custom-verdex.bin

Unser Target gumstix-custom-image vererbt dieses Verhalten, legt jedoch (s.o.) die Ramdisk direkt unter tmp/ramdisk.img ab

Anleitung, um einen eigenen Kernel zu generieren und mit Initframfs zu booten

Von SD-Card Booten

Im OpenMoko-Wiki steht beschrieben, wie man das so generierte Image auf eine SD-Card schreibt.

Patches einpflegen

Es ist möglich, dass eigene Patches bereitgestellt werden müssen. Diese Patches werden in dem Verzeichnis des Rezepts abgelegt, z. B. ${GUMSTIXTOP}/user.collection/package/linux/gumstix-kernel-2.6.21. Um BitBake zu veranlassen, diesen Patch auch einzuspielen, wird ein Zeile in dem Rezept eingefügt. ${GUMSTIXTOP}/user.collection/package/linux/gumstix-kernel_2.6.21.bb

...
+      file://sumversion.c.patch;patch=1 \
...


Manchmal ist es auch nötig eine neue Datei hinzuzufügen. Dazu geht man ähnlich vor wie bei den Patches:

  • Datei hinterlegen
  • Zeile zum Rezept hinzufügen (Allerdings ohne ";patch=1")
...
+      file://pni11096.c \
...
do_configure_prepend() {
...
+      cp ${WORKDIR}/pni11096.c ${S}/drivers/spi/
...

Links

Persönliche Werkzeuge