Tuxbox-Board

Ich habe das ganze Bauen via Yocto auf der ML soweit etwas mitverfolgt, aber selbst konnte ich noch kein einziges Ergebnis rausholen. Da gehts wahrscheinlich auch anderen so vorallem, wenn man da nicht unbedingt so viel Zeit dafür hat sich mit jedem Detail auseinander zu setzen, welches für den einen relativ unbedeutend ist, für den Interessierten aber schon fraglich ist, in welchen Pfad man jetzt dies oder das anlegen oder suchen und anpassen muss und nicht zuletzt warum das gemacht werden muss. Deshalb wäre es evtl. nicht schlecht, dies hier etwas detailiert zu beschreiben.
Soweit ich das rauslesen konnte ist das hier etwa die Basis wie es in der ML beschrieben wurde.

seife hat geschrieben: poky auschecken, dora branch (wichtig!)

git clone git://git.yoctoproject.org/poky yocto-poky
cd yocto-poky
git checkout -b dora origin/dora

Dann das neutrino-overlay: in welchem Verzeichnis wird hier geklont

git clone git://github.com/seife/meta-neutrino-mp.git

Dann noch einen BSP:

git clone git://github.com/seife/meta-tripledragon.git

Variablen setzen und buildverzeichnis initialisieren (build-td ist das Build-Verzeichnis und darin landet man auch gleich):

. oe-init-build-env build-td

Nun in conf/bblayers.conf die zwei zusätzlichen Layers meta-neutrino und meta-tripledragon eintragen: wo finde ich bblayers.conf

BBLAYERS ?= " \
/space/tmp/yocto-poky/meta \
/space/tmp/yocto-poky/meta-yocto \
/space/tmp/yocto-poky/meta-yocto-bsp \
/space/tmp/yocto-poky/meta-tripledragon \
/space/tmp/yocto-poky/meta-neutrino-mp \
"

(die Verzeichnisse heissen bei dir natürlich anders, einfach die meta-yocto zeile kopieren, zweimal einfügen und editieren).

Dann in conf/local.conf die gewünschten Einstellungen machen, besonders:

MACHINE = "tripledragon"

Ich habe noch

PACKAGE_CLASSES ?= "package_ipk package_rpm"
EXTRA_IMAGE_FEATURES += "package-management"

gemahct, damit ich sowohl RPM als auch ipk pakete bekomme. Die erste Paketart (ipk / opkg) ist auch die mit der das Image gebaut wird.
EXTRA_FEATURES sorgt dafür, dass im Image auch die Paketmetadaten und der Paketmanager (in diesem Fall opkg) mit drin ist, sonst kann man nichts nachinstallieren.

SOURCE_MIRROR_URL ?= "file:///local/seife/src/Archive"
INHERIT += "own-mirrors"

Damit werden Sachen, die schon in meinem Archive-Dir sind nicht nochmal runtergeladen.

Selbsterklärend:
BB_NUMBER_THREADS ?= "1"
PARALLEL_MAKE ?= "-j 3"

Ich habe nur einen Thread für bitbake, weil ich auf einer langsamen Platte baue, da bringt das wahrscheinlich nicht viel, aber eigentlich wird empfohlen soviele Threads wie CPU-Cores zu benutzen.

Wenn man kanpp an Plattenplatz ist, dann würde ich noch

INHERIT += "rm_work"

mit rein schreiben, damit werden temporäre Dateien weggeräumt, sobald ein Paket gebaut ist. Ansonsten liegt das rum und das summiert sich.
Selbst mit rm_work habe ich hier (3 Architekturen plus der Versuch, für die dbox ein overlay zu bauen) etwa 20GB auf der Platte liegen.

Auf der Yocto-Seite werden 50GB veranschlagt, allerdings bauen die eine recht vollständige distribution, inklusive X und Applikationen.

Ich habe dann noch das drin:

# see https://wiki.yoctoproject.org/wiki/PR_Service
PRSERV_HOST = "localhost:0"
INHERIT += "buildhistory"
BUILDHISTORY_COMMIT = "1"

Damit werden die Paketrevisionen automatisch hochgezählt falls nötig, was sehr praktisch ist.

Tja, und dann kann man mittels

bitbake neutrino-image

den Build anstarten. <- von wo, ist ja nicht global in PATH, PATH Umgebung anpassen?, Ein wenig später liegt dann das Image in tmp/deploy/images/tripledragon/neutrino-image-tripledragon.tar.gz

Trotz gemachter Einstellungen in local.conf

Code: Alles auswählen

bitbake neutrino-image
ERROR:  OE-core's config sanity checker detected a potential misconfiguration.
    Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).
    Following is the list of potential problems / advisories:

    Please set a valid MACHINE in your local.conf or environment

ERROR: Execution of event handler 'check_sanity_eventhandler' failed

wo finde ich bblayers.conf

conf ist ein Unterverzeichnis des zuvor angelegten Build-Verzeichnisses (im Beispieltext: build-td)
Darin sind dann die Konfigurationsdateien bblayers.conf, local.conf...

Mich würden doch ein paar mehr Infos zum Vorgehen für RaspberryPi interessieren.
Insbesondere, ob es direkt auf der Raspel funktioniert.
In einem ersten Versuch habe ich das dort mal bis zur Anpassung der Konfigurationen 'abgearbeitet'.
Da fehlten mir dann weitergehende Informationen. (meta-raspberrypi aus der ML kopieren ? MACHINE = raspberrypi ?)

Ich fürchte allerdings, dass ich doch ein 'richtiges' Linux-System verwenden muss ?!?
Kann ich nach Hardware-Wechsel erst noch aufbauen. Wenn ja, welche Distri sollte ich verwenden? Bisher habe ich Ubuntu (12.4.LTS), scheint aber in einigen Bereich nicht ganz yocto-konform zu sein, wenn man nicht wirklich sattelfest in Linux-Grundlagen ist...

Janus hat geschrieben:
Ich fürchte allerdings, dass ich doch ein 'richtiges' Linux-System verwenden muss ?!?

Also ich habe unter VM-Ware / Ubuntu 12.?? gebaut für die HD1 und das ging ohne Probleme.

dbt hat geschrieben:den Build anstarten. <- von wo, ist ja nicht global in PATH, PATH Umgebung anpassen?

Die Umgebung wird hiermit gesetzt:

Code: Alles auswählen

. oe-init-build-env build-td

Danach bits du in build-td, von dort wird der build gestartet

Houdini hat geschrieben:
dbt hat geschrieben:den Build anstarten. <- von wo, ist ja nicht global in PATH, PATH Umgebung anpassen?
Die Umgebung wird hiermit gesetzt:
Code: Alles auswählen
. oe-init-build-env build-td
Danach bits du in build-td, von dort wird der build gestartet

Ok, ich brauch manchmal schon 2 Tage länger...

aber anscheinend wirkt das nur temporär:

Code: Alles auswählen

/devel/yocto/yocto-poky/build-dir> bitbake neutrino-imageIf 'bitbake' is not a typo you can use command-not-found to lookup the package that contains it, like this:
    cnf bitbake

dann halt nochmal:

Code: Alles auswählen

. oe-init-build-env build-dir

### Shell environment set up for builds. ###

You can now run 'bitbake <target>'

Common targets are:
    core-image-minimal
    core-image-sato
    meta-toolchain
    meta-toolchain-sdk
    adt-installer
    meta-ide-support

You can also run generated qemu images with a command like 'runqemu qemux86'

Nächster Versuch, wieder nix

Code: Alles auswählen

dbt@linux-11-3:~/devel/yocto/yocto-poky/build-dir> bitbake neutrino-image
ERROR:  OE-core's config sanity checker detected a potential misconfiguration.
    Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).
    Following is the list of potential problems / advisories:

    Please set a MACHINE in your local.conf or environment

ERROR: Execution of event handler 'check_sanity_eventhandler' failed
dbt@linux-11-3:~/devel/yocto/yocto-poky/build-dir>

...und ich bin mir sicher, dass ich das so angepasst habe, wie oben beschrieben, halt den kokalen Gegebenheiten entsprechend.

Bei mir lief es für die coolstream durch,

Code: Alles auswählen

harald@Houdini64:~/tuxbox-cvs/yocto-poky/build-hd1$ cat conf/local.conf | grep MACHINE
#MACHINE ?= "qemuarm"
#MACHINE ?= "qemumips"
#MACHINE ?= "qemuppc"
#MACHINE ?= "qemux86"
#MACHINE ?= "qemux86-64"
MACHINE = "coolstream"
#MACHINE ?= "beagleboard"
#MACHINE ?= "genericx86"
#MACHINE ?= "genericx86-64"
#MACHINE ?= "mpc8315e-rdb"
#MACHINE ?= "routerstationpro"
MACHINE ??= "qemux86"
#SDKMACHINE ?= "i686"

Hier weder mit Triple noch Coolstream.

ich habe natürlich auch seifes coolstream meta layer benutzt

Code: Alles auswählen

git clone git://github.com/seife/meta-coolstream.git meta-coolstream-hd1

und in die bblayers.conf eingetragen

Code: Alles auswählen

  /home/harald/tuxbox-cvs/yocto-poky/meta-coolstream-hd1 \

Houdini hat geschrieben:...
und in die bblayers.conf eingetragen
Code: Alles auswählen
  /home/harald/tuxbox-cvs/yocto-poky/meta-coolstream-hd1 \

Thx...und war tatsächlich das Problem, hatte das einfach als letztes angefügt, statt einzufügen. Jetzt hats durchgebaut. Jetzt erschlägts einen allerdings fast, bei dem was hinten rausfällt.

Wie kann man da denn jetzt eine zusätzliche Lib einbauen, wenn diese als Abhängigkeit benötigt wird?

Bin mir nicht ganz sicher, ob ich deine Frage richtig verstanden habe. Drum geb ich gleich mal mehrere Antworten

Die foo.bb files in den Recipe Ordnern entsprechen in etwa den make Targets aus dem alten BS.
Als Beispiel hier mal ein bb für xupnpd:

Code: Alles auswählen

# Copyright (C) 2012 Igor Drach
# leaigor@gmail.com

DESCRIPTION = "xupnpd - eXtensible UPnP agent"
HOMEPAGE = "http://xupnpd.org"

LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://../LICENSE;md5=751419260aa954499f7abaabaa882bbe"

DEPENDS += "lua5.2"
PR = "r12"
SRCREV = "392"
SRC_URI = "svn://tsdemuxer.googlecode.com/svn/trunk;protocol=http;module=xupnpd \
file://xupnpd.init \
file://xupnpd.lua"
S = "${WORKDIR}/xupnpd/src"

inherit base


SRC = "main.cpp soap.cpp mem.cpp mcast.cpp luaxlib.cpp luaxcore.cpp luajson.cpp luajson_parser.cpp"

do_compile () {
${CC} -O2 -c -o md5.o md5c.c
${CC} ${CFLAGS} ${LDFLAGS} -DWITH_URANDOM -o xupnpd ${SRC} md5.o -llua -lm -ldl -lstdc++
}


do_install () {
install -d ${D}/usr/bin ${D}/usr/share/xupnpd ${D}/usr/share/xupnpd/config ${D}/usr/share/xupnpd/playlists ${D}/etc/init.d
cp ${WORKDIR}/xupnpd.init ${D}/etc/init.d/xupnpd
cp ${S}/xupnpd ${D}/usr/bin/
cp -r ${S}/plugins ${D}/usr/share/xupnpd/
cp -r ${S}/profiles ${D}/usr/share/xupnpd/
cp -r ${S}/ui ${D}/usr/share/xupnpd/
cp -r ${S}/www ${D}/usr/share/xupnpd/
cp ${S}/*.lua ${D}/usr/share/xupnpd/
cp ${WORKDIR}/xupnpd.lua ${D}/usr/share/xupnpd/

Abhängigkeiten werden in dem Beispiel dort angegeben:

Code: Alles auswählen

DEPENDS += "lua5.2"

Wenn beispielsweise xupnpd gleich mit im Image landen soll, musst Du diese Zeile am Ende der conf/local.conf einfügen:

Code: Alles auswählen

IMAGE_INSTALL_append += "xupnpd"

Diese Zeile kann beliebig erweitert werden:

Code: Alles auswählen

IMAGE_INSTALL_append += "xupnpd ushare nano"

Ich hätte auch noch eine Frage. Mir ist aufgefallen, dass die Packages* Dateien in tmp/deploy/ipkg/armv6/ nicht aktualisiert werden, wenn man neue Pakete baut. Wenn ich mit rsync den Ordner mit dem Webserver abgleiche, werden zwar die Pakete übertragen, ich kann aber nichts über opkg-cl installieren, weil die md5 Summen nicht stimmen. Abhilfe schafft es, bitbake neutrino-image auszuführen, danach sind die Packages* aktuell und ich kann upgraden.

Gibt es einen Befehl für die Aktualisierung bzw. sollte das nicht automatisch passieren ?

Beim Aktualisieren von Neutrino habe ich auch noch Probleme:

Code: Alles auswählen

root@coolstream:~# opkg-cl install --force-reinstall neutrino-mp
Removing package neutrino-mp from root...
start-stop-daemon: unable to stat //neutrino (No such file or directory)
Installing neutrino-mp (0.0+git0+bbd0a5e27a-r23) to root...
Downloading http://xxxxxxxxx/opk/coolstream/neutrino-mp_0.0+git0+bbd0a5e27a-r22_armv6.ipk.
neutrino-mp: unsatisfied recommendation for update-rc.d
Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for neutrino-mp:
 *      tzdata *        cs-drivers (>= 0.0+git0+32f81e3c3c) * 
 * opkg_install_cmd: Cannot install package neutrino-mp.
root@coolstream:~# opkg-cl install --force-reinstall --force-depends neutrino-mp
No packages removed.
Installing neutrino-mp (0.0+git0+bbd0a5e27a-r23) to root...
Downloading http://xxxxxxxx/opk/coolstream/neutrino-mp_0.0+git0+bbd0a5e27a-r23_armv6.ipk.
neutrino-mp: unsatisfied recommendation for update-rc.d
Configuring neutrino-mp.
update-alternatives: Linking //bin/backup.sh to /usr/bin/backup.sh
update-alternatives: Linking //bin/install.sh to /usr/bin/install.sh
update-alternatives: Linking //bin/restore.sh to /usr/bin/restore.sh
Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for neutrino-mp:
 *      tzdata *        cs-drivers (>= 0.0+git0+32f81e3c3c) *

mit

Code: Alles auswählen

force-depends

klappts .... und läuft dann auch problemlos

flk hat geschrieben:Ich hätte auch noch eine Frage. Mir ist aufgefallen, dass die Packages* Dateien in tmp/deploy/ipkg/armv6/ nicht aktualisiert werden, wenn man neue Pakete baut.
...
Gibt es einen Befehl für die Aktualisierung bzw. sollte das nicht automatisch passieren ?

"bitbake package-index"
"bitbake-layers show-recipes" zeigt übrigens alle verfügbaren targets.

Beim Bau für RaspberryPi klemmts noch.

Code: Alles auswählen

Parsing recipes: 100% |###################################################################################| Time: 00:00:37
Parsing of 904 .bb files complete (0 cached, 904 parsed). 1240 targets, 39 skipped, 1 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing RPROVIDES 'kernel-modulesdjmount' (but /home/flk/build/yocto-poky/meta-neutrino-mp/recipes-images/images/neutrino-image.bb RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'kernel-modulesdjmount' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['kernel-modulesdjmount']
ERROR: Required build target 'neutrino-image' has no buildable providers.
Missing or unbuildable dependency chain was: ['neutrino-image', 'kernel-modulesdjmount']

Wird in

meta-neutrino-mp/recipes-images/images/neutrino-image.bb

Code: Alles auswählen

IMAGE_INSTALL += "${@'kernel-modules' if MACHINE != 'coolstream' else ''}"

in

Code: Alles auswählen

IMAGE_INSTALL += "${@'kernel-modules ' if MACHINE != 'coolstream' else ''}"

geändert, also hinter kernel-modules ein Leerzeichen eingefügt, dann läufts.

Da musst du aber noch was anderes geändert haben, weil djmount ja im recipes-images/images/neutrino-image.bb in IMAGE_INSTALL eingefügt wird, und davor und dahinter andere sachen kommen, also kernel-modules kann da nicht davor sein.

=> das Leerzeichen ist zwar ein Workaround, aber das Problem muss IMHO lokal bei dir woanders liegen.

Stimmt, jetzt wo Du s sagst

Ich habe die local.conf von meinem Coolstream Build angepasst. Als ich die erstellt hatte, gabs noch kein djmount in deinem Image, deshalb hatte ich s in der local.conf unter

Code: Alles auswählen

IMAGE_INSTALL_append = "djmount"

stehen. Da liegt das Problem. Macht mehr Sinn, das Leerzeichen da voranzustellen. Dann muss ich nicht in Deinen Layern rumpfuschen.

hm, aber funktionieren sollte das natürlich trotzdem...
Beim "+=" ist immer ein Leerzeichen mit dabei, aber bei _append anscheinend nicht.
Aber egal wer "schuld" ist, mit dem Leerzeichen in deiner config bist du auf der sicheren Seite

Bei do_rootfs krieg ich noch einen error:

Code: Alles auswählen

Computing transaction...error: Can't install autofs-4.1.4-r11@armv6_vfp: no package provides kernel-module-autofs4

Ohne autofs baut das durch

Da fehlt im raspi-kernel vermutlich das CONFIG_AUTOFS4=m, evtl. ist es ja fix einkompiliert? Ich habe das schon ewig nicht mehr probiert.

Wenn per Default kein autofs im Raspberry Kernel ist, müsst man den Build doch auch so in der neutrino-image.bb fixen können:

Code: Alles auswählen

# There is no support for autofs in the raspberrypi kernel
IMAGE_INSTALL += "${@'autofs' if MACHINE != 'raspberrypi' else ''}"

Soweit ich sehe ist das im Raspi-Kernel fest eingebaut. Also müsste der Kernel das modul providen, weil es eingebaut ist.

Müsste man wohl mit OE- und/oder yocto-Upstream mal diskutieren.

Habe gerade in der autofs.bb gesehen, dass du das Problem schon vorhergesehen hast

Muss man sich halt vorerst lokal zurecht biegen. Apropos lokal ... wäre es möglich, xupnpd und udpxy in recipes-local aufzunehmen ? Allerdings ist udpxy gplv3 or later. Aber solange das nur im Quellcode vorliegt bzw. nicht gewerblich Nutzung findet, sollte das ja egal sein ?

xupnpd.tar.gz

wegen xupnpd: ein pull-request ginge schneller, ich schau's mir aber an. GPL3 ist nicht relevant, weil es ja nirgends gegen gelinkt wird, oder täusche ich mich da? Das ist doch standalone?

autofs4 module dependency habe ich versucht zu fixen, ich habe jetzt aber nicht nochmals "from scratch" gebaut.

seife hat geschrieben:ein pull-request ginge schneller

Werde ich beim nächsten Mal machen. Habe mir nur gedacht, dass es nicht schadet, wenn man da vorher noch mal drüber schaut. Baut zwar bei mir so, das heisst aber ja nicht, dass da nicht noch einige Fehler drin sein könnten.

autofs4 module dependency habe ich versucht zu fixen, ich habe jetzt aber nicht nochmals "from scratch" gebaut.

Mit völlig "nacktem" build Ordner kommt bei mir das:

NOTE: Error during finalise of /home/flk/build/yocto-poky/meta-neutrino-mp/recipes-local/autofs/autofs_4.1.4.bb
ERROR: ExpansionError during parsing /home/flk/build/yocto-poky/meta-neutrino-mp/recipes-local/autofs/autofs_4.1.4.bb: Failure expanding variable RDEPENDS_autofs: ExpansionError: Failure expanding variable RDEPENDS_autofs, expression was procps ${@autofs4_module_dep(bb, d)} which triggered exception IOError: [Errno 2] No such file or directory: '/home/flk/build/tmp/sysroots/raspberrypi/usr/src/kernel/.config'

hm, ich hatte gehofft das durch
DEPENDS += "virtual/kernel"
reingeholt zu haben, aber gut, dann müssen wir halt weiter schauen wie man das löst. Muss man halt den Kernel erst mal manuell bauen

Edit: ok, ich sehe da gibt's ein "bootstrap-problem". Bin am experimentieren

Edit2: jetzt sollte es wieder gehen (build from scratch getestet für Raspi und hd1)

Tuxbox-Board

Yocto

Yocto

Re: Yocto

Re: Yocto

Re: Yocto

Re: Yocto

Re: Yocto

Re: Yocto

Re: Yocto

Re: Yocto

Re: Yocto

Re: Yocto

Re: Yocto

Re: Yocto

Re: Yocto

Re: Yocto

Re: Yocto

Re: Yocto

Re: Yocto

Re: Yocto

Re: Yocto

Re: Yocto

Re: Yocto

Re: Yocto

Re: Yocto

Re: Yocto