![[IPv4/6]](/images/ip_proto.php "This beacon shows the currently used ip protocol (ipv4 or ipv6) for this connection"){kind=small}
Wie kommt Linux auf mein Produkt?
Quick Links
- OSELAS.BSP( ) Editions:
[Minimum] [Standard] [Web] [GUI] - Artikel: Booting Linux Fast & Fancy
CD einlegen, ein paar Klicks und schwupp! Schon ist Linux auf einem neuen Gerät drauf und man kann viele tolle Applikationen nutzen und eigene entwickeln. Ganz einfach...?
Im Industrie-Umfeld stoßen Wunsch und Wirklichkeit aufeinander und es stellt sich schnell heraus, dass man mehr tun muss, um ein Custom Produkt mit Linux zu unterstützen:
- Bootloader: Im Gegensatz zum x86 PC gibt es kein BIOS, d.h. es muß ein Bootloader portiert werden. Der Bootloader lädt Linux vom Bootmedium (Flash oder Netzwerk), richtet die Hardware ein und startet Linux. Wir empfehlen den Bootloader Barebox.
- Kernel Port & Treiber: Längst nicht alle Prozessoren, die aus anderen Gründen (z.B. Preis, Peripherie) zu einem Produkt passen, sind auch vollständig im Linux Kernel unterstützt. Und auch wenn die CPU unterstützt ist, muss der Kernel an die eigene Periphierie angepasst werden. Für noch nicht unterstützte und eigene Hardware müssen Treiber erstellt werden.
- Optimierung: Das System sollte für die Anwendung optimiert werden. Dazu kann der Einsatz eines zum Prozessor genau passenden Compilers ebenso gehören wie die Bootzeitoptimierung und das Beseitigen von grafischen Artefakten (Flicker beim Booten).
- Integration: Aus allen Komponenten (Kernel, Treiber, Bibliotheken und Services) muss ein System integriert und getestet werden. Dabei müssen Komfort und Kosten abgewägt werden: Standard- Distributionen etwa bieten vieles fertig, wohingegen sich mit optimierten Systemen viel Platz und somit Produktionszeit sparen läßt.
All diese Schritte fassen wir unter dem Thema "Board Support Package" zusammen. Ein BSP beinhaltet alle benötigten Software-Komponenten und bereitet diese gebrauchsfähig auf, so dass der Anwender nur noch seine eigene Applikation in das System integrieren muss. Wir erstellen Ihr kundenspezifisches BSP.
Wichtige Features für BSPs
Nachvollzug: Die wahre Stärke von Open Source Software liegt nicht allein darin, dass der Sourcecode offenliegt. Viel wichtiger ist, dass man diesen auch instrumentieren und das System aus den Sourcen erneut bauen kann.
Mainline: Je weniger die Komponenten eines BSPs von den Versionen der originalen Autoren abweicht, um so höher ist die weltweite Testabdeckung und um so geringer die Gefahr, dass man sich mit eigenen Änderungen in Sackgassen verirrt, die langfristig nicht zu pflegen sind. Dies gilt besonders für den Kernel. Deshalb basieren unsere BSPs auf dem offiziellen Mainline Kernel von Linus Torvalds. Alle notwendigen Patche werden entsprechend den Kernel-Standards erstellt und im Canonical Patch Format dokumentiert.
Kein Vendor-Lock-In: Linux löst Probleme von Anwendern. Deshalb ist es wichtig, dass ein BSP keine unnötigen Abhängigkeiten zu Herstellern erzeugt. Unsere BSPs sind vollständig offen, es sind keine proprietären Tools im Spiel. So kann der Kunde bei Bedarf alles selbst tun und ist nicht von uns abhängig.
Vorgehensmodell
| Vorbereitungsphase | Aktivitäten |
|---|---|
| Vorstellung Projektidee | Kunde stellt Projekt grob vor, Pengutronix stellt Möglichkeiten vor. Falls Lastenheft vorliegt, Erstellung eines Budget-Angebots. Falls nicht, Unterstützung bei der Erstellung eines Lastenhefts (Consulting). |
| Planungsphase | Aktivitäten |
|---|---|
| Requirements Workshop | Kunde stellt Projekt vor, Diskussion aller funktionalen Anforderungen, Vorstellung der Möglichkeiten von Hardware und Software. Erstellung eines Protokolls. |
| Lastenheft+Pflichtenheft | Kunde erstellt Lastenheft, Pengutronix erstellt Pflichtenheft. Diskussion über Möglichkeiten und Anforderungen. |
| Abschätzung+Auftrag | Pengutronix erstellt Aufwandsabschätzung als Grundlage für Angebot. Kunde beauftragt Projekt. |
| Entwicklungsphase | Aktivitäten |
|---|---|
| Iteration 1 | Umsetzung von Arbeitspunkten durch das Pengutronix Kernel-Team, Dokumentation, Auslieferung von Ergebnissen (via RCS), Test und Inbetriebnahme, ggf. Anpassung der Spezifikationen. Mainlining von abgeschlossenen Komponenten. |
| Iteration 2...N | ... |
| Übergabephase | Aktivitäten |
|---|---|
| Abnahme | Gemeinsame Abnahme einer Release-Version. |
| Ausblick | Diskussion möglicher weiterer Funktionalitäten und Entwicklungsschritte. |
Weitere Infos
- Kontakt: Herr Robert Schwebel