Freetz auf OpenEmbedded?

amix

Neuer User
Mitglied seit
7 Aug 2009
Beiträge
82
Punkte für Reaktionen
0
Punkte
0
Hallo,

hat sich denn schon mal jemand mit OpenEmbedded beschäftigt? Ich sehe, daß es patches gibt, die von dort übernomen werden und in Freetz einlaufen.

Der Grund warum ich überhaupt darüber nachdenke, ob es nicht vorteilhaft wäre, Freetz auf OpenEmbedded als Grundlage zu gestalten, sind die über 1000 Pakete, die es bereits an OpenEmbedded angepasst gibt. Sofern ich OE richtig verstanden habe, werden plattformspezifische Unterschiede durch patches gelöst, die über das BitBaker Framework injiziert werden.

Es scheint:
*) OpenEmbedded wurde ursprünglich für ARM CPUs geschaffen.
*) OpenEmbedded ist bereits als Paket für die meisten LinuxDistros vorhanden. Das hieße, daß man sich das mit dem Package-Manager seiner Wahl installiert (also deren cross-compiler toolchain und ihr meta-framework)
*) OpenEmbedded läuft auch unter OS X native.
*) OpenEmbedded läuft jedoch *nicht* unter Windows/Cygwin. Der Port-Versuch führt zu einem 404. Ansonsten hätte man auch auf die Wartung einer Freetz-VM verzichten können.
*) Es gibt über 1000 Pakete, die für Embedded Devices interessant sind. Das wäre der Part, an dem Freetz enorm profitieren würde.

Ich habe mich nur oberflächlich damit beschäftigt (drüber gelesen). Auch möchte ich nicht, daß dies hier als Kritik am jetzigen build-system verstanden wird, denn ich finde es schon ganz schön beeindruckend, was die Entwickler von Freetz geleistet haben. Und es läuft ja auch anscheinend ganz gut ("never change a running team")

Der Gedanke ist halt, daß an OE viel mehr Leute mitarbeiten, Firmen, z.B. und man somit von der geteilten Arbeit profitiert (und sich auch sicherlich ne Menge neue Probleme einhandelt, lol).

Über 1000 Pakete...! Brums. Brums. :D
 
Weißt Du auch, was der Unterschied zu OpenWRT ist?
Vermutlich wird das Problem sein, dass die Firmware komplett ersetzt werden soll, und damit die AVM-Funktionen alle weg sind.
 
Ich bin mir nicht ganz sicher, ob ich Dir folgen kann.

Wie gesagt, ich bin das Ganze nur schnell überflogen, aber soweit ich weiß ist das Besondere an OE das BitBaker framework, welches ein Meta Paket Manager / Build Umgebung zu sein scheint. Da müsste man doch flexibel bleiben können.
 
Ich habe auch mal etwas auf der Seite gelesen, habe aber die 1000 Pakete nicht gefunden.

Konkret ist es auf jeden Fall Arbeit, alles was schon vorhanden ist, zu ändern. Die Frage wäre also, ob man sich auf lange Sicht mit der Umstellung das Leben leichter macht. Und zunächst wird es auf jeden Fall komplizierter, wenn man sich mit den neuen Werkzeugen nicht auskennt.

Im Fall von Freetz kommt noch dazu, dass die AVM Firmware erhalten bleiben soll, ich weiß nicht, inwieweit das ins Konzept von OpenEmbedded passt.
 
Ich hatte auch schon mit dem Gedanken gespielt Freetz als Teil in OpenWRT zu integrieren. Toolchain, Kernel und Pakete lassen sich ja "einfach" übernehmen. Aber mir ist keine Lösung für die Einbindung der zahlreichen Firmwares eingefallen.

Gruß
Oliver
 
OpenWRT hat auch eine wesentlich längere Liste von unterstützter Hardware als OpenEmbedded, auch wenn das allein sicher nicht entscheidend ist.

Prinzipiell finde ich die Idee eines Paket-Managers gut, in welcher Form auch immer. Also insbesondere, dass beim Installieren von neuen Libraries die alten Versionen entfernt werden. Ich hatte schon mal das Problem, dass zwei Versionen einer Library vorhanden waren, die dann auch beide in die Firmware gepackt wurden, und ich hatte mich gewundert, warum der Platz plötzlich nicht mehr reicht.

Irgendwer hat sich doch eine bessere Beschreibung unserer Makefiles gewünscht. Wenn ich etwas Zeit habe, mache ich einige Änderungen einschließlich Beschreibung.
 
Das war reiffert im Bounty Thread. Wir haben aber noch keine Höhe für das Bounty festegelegt. ;-)

Gruß
Oliver
 
Ich habe auch mal etwas auf der Seite gelesen, habe aber die 1000 Pakete nicht gefunden.
Steht gleich auf der Frontpage in der letzten Zeile der Beschreibung:
http://www.openembedded.org/wiki/Main_Page schrieb:
Welcome to OpenEmbedded, the build framework for embedded Linux. OpenEmbedded offers a best-in-class cross-compile environment. It allows developers to create a complete Linux Distribution for embedded systems. Some of the OpenEmbedded advantages include:

support for many hardware architectures
multiple releases for those architectures
tools for speeding up the process of recreating the base after changes have been made
easy to customize
runs on any Linux distribution
cross-compiles 1000's of packages including GTK+, Qt, the X Windows system, Mono, Java, and about anything else you might ever need
Hier habe ich einige "Reciepes" gefunden ("show tree" anwählen):
http://cgit.openembedded.org/cgit.cgi/meta-openembedded/tree/meta-oe
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/tree/meta
Die scheinen ein Perl zu haben ;-) Ist in reciepes-extended.
Konkret ist es auf jeden Fall Arbeit, alles was schon vorhanden ist, zu ändern. Die Frage wäre also, ob man sich auf lange Sicht mit der Umstellung das Leben leichter macht. Und zunächst wird es auf jeden Fall komplizierter, wenn man sich mit den neuen Werkzeugen nicht auskennt.
Das ist absolut richtig. Die Frage, ob man wirklich etwas gewinnen würde, ist für mich, der sich mit Freetz nur oberflächlich auskennt (ein, zwei Pakete erstellt, mal geguckt, ob sich die Build Umgebung an OS X anpassen ließe), sowieso nicht zu beantworten. Auf der einen Seite würde man ein gut strukturiertes, professionelles, dokumentiertes Projekt erhalten, an dem viele Firmen aus einem ähnlichen Tätigkeitsbereich mitarbeiten, auf der anderen Seite will das Ganze auch erst mal umgestellt (und Komplikationen kündigen sich nie vorher an) und absorbiert werden.
Im Fall von Freetz kommt noch dazu, dass die AVM Firmware erhalten bleiben soll, ich weiß nicht, inwieweit das ins Konzept von OpenEmbedded passt.
Dazu kann ich überhaupt nichts sagen. Ich verstehe das technische Problem nur oberflächlich. Aber da wir ja auch einen Kernel kompilieren können und nebenbei Pakete erstellen... Und wenn die Firmware wir ein Paket behandelt würde, das Abhängigkeiten erfüllt? Das ließe sich sicherlich in BitBake scripts definieren, welche ja beschreiben, wie ein Paket zu bauen ist. Aber wie gesagt, ich bin da nicht so der Know-Howy. :?
 
Zuletzt bearbeitet:
OpenWRT wäre vielleicht sogar wirklich interessanter, da dort natürlich das Ziel quasi identisch ist mit dem von Freetz und gerade daher die Pakete und Details stimmen.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.