"Easy Setup" für Yocto/meta-neutrino-mp

[seife]

Hallo,
ich habe mal ein kleines Skript gemacht, was das aufsetzen einer Yocto-Umgebung um neutrino-MP zu bauen etwas vereinfacht. Zu benutzen wie folgt:

Code: Alles auswählen

wget https://github.com/seife/meta-neutrino-mp/raw/master/doc/prepare-yocto-neutrino.sh
chmod +x prepare-yocto-neutrino.sh
./prepare-yocto-neutrino.sh tripledragon

Ohne Parameter kommt ein kurzer Hilfetext:

Code: Alles auswählen

> ./prepare-yocto-neutrino.sh
usage: prepare-yocto-neutrino.sh <machine>
supported machines are:
 * "tripledragon" -- the TripleDragon Armas DBS3000 set-top-box
 * "coolstream" -- Coolstream HD1 set-top-box (so-called "Nevis" platform
 * "raspberrypi" -- the RaspberryPi computer
 * "spark" -- Fulan SPARK (STi7111 and STi7162 based) set-top-boxes

Das Skript macht folgendes:

• yocto-poky auschecken
• meta-neutrino-mp auschecken
• eine Konfigdatei anlegen, die prinzipiell passen sollte

Das Skript sagt am Ende, was man danach tun sollte:

• in das Verzeichnis wechseln (yocto-poky-*)
• . oe-init-build-env build-* aufrufen
• in conf/local.conf reinschauen, "meine" Einstellungen sind ganz unten, da sind noch ein paar Sachen mit Kommentaren, was man einschalten kann. Dazu auch mal in https://www.yoctoproject.org/documentation nachschauen...

Die genauen Verzeichnisnamen sind abhängig von der gewählten Plattform, das Skript sagt euch die an.

Prinzipiell scheint es zu funktionieren, ein damit gebautes USB-Stick-Image habe ich auf einer Coolstream neo sowie auf einer GM Triplex (SPARK7162) erfolgreich gebootet, einen Tarball (weil Images gibt es dort ja nicht) auf der Tripledragon. Es hat wesentlich besser funktioniert als ich ursprünglich vermutet habe.

Wer relativ einfach lokal (ohne Paket zu bauen und installieren) binaries zum Testen bauen will, dann sich dann mal im meta-neutrino-mp/doc/Makefile.SDK bzw. dem dazugehörigen README umschauen, das mit dem SDK ist meiner Meinung nach eines der Killerfeatures vom yocto/OE überhaupt.

Viel Spaß

Ein paar technische Details noch:

• Es wird yocto release dizzy (1.7) verwendet, außer auf der Tripledragon. Weil die mit Kernel 2.6.12 maximal glibc 2.16 benutzen kann, bleibe ich dort bei daisy (1.6).
• Für Spark und Spark7162 gibt es nur ein Image, die Unterschiede (nur Kernel und ein paar wenige Treiber) werden zur Laufzeit abgehandelt
• Flashimages sind nicht getestet, wie immer

[D_B]

Dann sage ich mal Danke schön .

Eine Frage brennt mir aber auf der Zunge, was macht neutrino mit dem raspberrypi ?

Wenn man mit diesem dann DVB T S oder C schaun kann, macht das Sinn ?
Oder muss man beim Umschalten 10 sec. warten ?

schönen Karneval

[seife]

Ich hab neutrino auf dem raspi schon seit ca 1 Jahr nicht mehr probiert. Ist in diesem Thread aber offtopic
VDR geht sehr schön auf dem raspi, auch mit SAT>IP input plugin

[Benny]

"Easy Setup" für Yocto/meta-neutrino-mp

Thanks, it really easy, only one correction was made - for firmware path. Everything else was builded without any notch.

Questions:
- cs-build have many "make-targets", so if i need to rebuild only one package, i should just write 'make target-pkg'. How i can rebuild same package with yocto-build - 'bitbake target-pkg', or there is only one global recipe 'neutrino-image'?

- seife, can you, as expert, give some comments on this build system (pros and cons, comparable to cs-build, for example)?
As for me, cons:
- it builds a lot "unneccesary" stuff, as result
- build time is way too long (only for first time, may be);
- it consumes a lot of disk space (15 GB in my case) during build and do not frees disk space after;
Pros:
- "Standard" buildsystem. Many images nowadays has builded in OE/yocto environment.
- As your experience proved - its relatively easy to adapt anything for it.

[MPC823]

Danke auch wenn es wie üblich ohne finetuning bei mir nicht gehr. Der PPC hat weniger probleme gemacht als nun die Intel Build Platform.

PPC ist tot , es lebe der Power PC

M

[seife]

Benny: there are lots of excellent tutorials on openembedded / yocto on the web. Start at https://www.yoctoproject.org/documentation.

I don't know what "cs-build" is, so I cannot comment on that.
I can compare it to my own, deprecated "buildsystem" that was hosted at https://gitorious.org/neutrino-hd/buildsystem-cs/

Pros of yocto/OE:

• the SDK. Being able to simply build a self-contained SDK which I then can take to any machine is very useful
• it's doing stuff right, most of the time. Means: great effort is taken to ensure that only target headers are included, and not those of the host. Everything needed for crossbuild is built for cross-building instead of (e.g.) abusing the host's pkg-config for cross build
• the SDK.
• it is maintained by someone else, who most often knows much more about the subject than I do
• the SDK
• I can do the thing that interests me most, instead of having to maintain crossbuild scripts etc
• did I already mention the SDK?
• Packages generation and package management is fully automatic and integrated. I can easily choose the package format and the package management system I like. For example we thought about switching away from opkg to plain deb because opkg has some limitations. It would be a simple configuration variable switch.

The cons of yocto/OE are not really cons for me, because:

• Disk space is cheap. My work is not.
• It builds lots of stuff, but you don't need to install it. With some work, it would certainly be possible to prune the dependencies, but see above: Disk space and CPU time is cheap. My work is not.

There are no Pros for the old buildsystem-cs.
Cons:

• It's broken. It does many things wrong and often those will cause subtle errors, which are hard to debug later. I know, because I designed and implemented it. Once you realise that you failed on something, it's time to move on.
• It really is broken. Often it will include the host's headers without complaing. Most often seen if people ask "I got this compilation error about ssl.h not found", someone else asks "you need to install openssl-devel", and the error goes away. Even this might seem to have worked, it shows the fundamental flaw: including host's headers is evil. Period.

The only thing I'm keeping the old buildsystem-cs "alive" for right now is because yocto is going ahead with always current versions, while I cannot update the Triple dragon beyond eglibc-2.16 (the last version to support kernel 2.6.12). So once branch daisy is abandoned and no longer usable in newer environments (a few years from now, I guess), I'll either have to start keeping daisy usable, pull the eglibc-2.16 build into meta-tripledragon, or just use buildsystem-cs again for TD only then. Chances are, that the last Triple Dragon is no longer used then (I'd guess I can count the users of neutrino on TD on the fingers of one, maybe two hands today ) and we can just drop that target.

[seife]

Danke auch wenn es wie üblich ohne finetuning bei mir nicht gehr.

Was musstet du tunen? Der Plan war, daß es einfach funktioniert.

[Benny]

I don't know what "cs-build" is

This

my own, deprecated "buildsystem"

i'm used to it - it's simple, fast, and rather effective. After it yocto buildsystem looks like "black box" to me.
And there always some workaround exist for some caveats, so this is not a big issue =)

Anyway, thank you for detailed explanation.

[Tann]

flash funktionierte bei mehreren die es getestet hatten nicht
nur usb

[seife]

bei mir schon
Edit: ich muß aber zugeben, ich habe es nur auf spark mit dem 0217 kernel und DDT-Treiber probiert. Es kann also sein, daß flashen auf coolstream oder Raspberrypi nicht funktioniert.

[seife]

Das Skript ist wieder raus, da es die User zu stark verwirrt hat.

[Oldtimer56]

Ich hatte vor einiger Zeit auch mal das Neutrino-MP mit yocto für Spark7162 gebaut:
Baute soweit durch, bis auf die elfen, da musste ich den Pfad anpassen die wollten einfach nicht gefunden werden.
Den Tarball sowie passenden Kernel hab ich dann mit dem DDT zu einem Flashimage verarbeitet.
Das Image startete auch, allerdings meckerte Neutrino das fehlende /dev/lirc an.
Ein Symlink nach lirc0 dann klappte auch das.
Bei der Wiedergabe von *.ts Files waren allerdings immer wieder Verpixelungen im Bild.
Und irgendwie konnte ich immer nur einmal starten: beim nächsten Boot meckerte der U-Boot den Kernel-mtd an.
Nur den Kernel neu geflasht, da startete das Image ( einmal ) wieder.
(Liegt möglicherweise auch daran das ich den mtd1 und mtd4 der ehemaligen plötzlich verschwundenen Spark Soft für experimentelles nutze.)

Ich hab dann mal das gleiche Neutrino inkl. Libhal mit der DDT Basis (gcc-4.8.4) gebaut: Lief dann einwandfrei flüssig, auch keine Verpixelungen mehr bei *.ts Wiedergabe.

Ansonsten mal ein interessantes Experiment.