![[IPv4/6]](/images/ip_proto.php "This beacon shows the currently used ip protocol (ipv4 or ipv6) for this connection"){kind=small}
How do I get Linux onto my Product?
Quick Links
- OSELAS.BSP( ) Editions:
[Minimum] [Standard] [Web] [GUI] - Article: Booting Linux Fast & Fancy
Insert CD, a couple of clicks and voilà, Linux is installed on a new device, a wide selection of great applications can be used and own applications can be developed. Very simple...?
In the industrial environment, wishful thinking meets reality and it quickly turns out that more has to be done in order to truly support a custom product with Linux:
- Boot loader: Contrary to the x86 PC there is no BIOS, that means a boot loader needs to be ported. The boot loader loads Linux from the boot medium (flash or network), configures the hardware and starts Linux. We recommend the boot loader Barebox.
- Kernel port & drivers: not all processors which suit a product (e.g. for reasons of price or peripherals) are also fully supported by the Linux kernel. And even if the CPU is supported, the kernel needs to be adjusted to the respective peripherals. Also, drivers need to be developed for not-yet-supported and custom hardware.
- Optimisation: the system should be optimised for the application. This can include the use of a compiler that exactly fits the processor as well as boot time optimisation and the elimination of graphical artefacts (flicker-free booting).
- Integration: a system has to be integrated from all components (kernel, drivers, libraries and services) and then tested. Doing this, comfort and cost need to be balanced carefully: standard distributions for instance offer everything ready-made, while optimised systems can help saving space and thus production time.
We combine all these steps in a so called "Board Support Package" (BSP). A BSP includes all necessary software components and prepares them ready-for-use, so that the only task left to the user is integrating the application. We build your customer-specific BSP.
Important Features of BSPs
Reproducibility: the true strength of open source software lies not only in the fact that its source code is freely available. Much more importantly it can be instrumented and recompiled from the sources.
Mainline: the less the components of a BSP deviate from the versions of the original authors, the higher the worldwide test coverage and the smaller the risk of getting one's code into a dead end that cannot be maintained in the long term. This is especially true for the kernel. Because of this, our BSPs are based on the official mainline kernel by Linus Torvalds. All necessary patches are created according to kernel standards and in canonical patch format.
No vendor-lock-in: Linux solves user problems. Because of this it is important that a BSP creates no unnecessary dependencies on manufacturers. Our BSPs are completely open, there are no proprietary tools involved. This way the customer can, if required, recreate everything and does not have to depend on us.
Process Model
| Preparation Phase | Activities |
|---|---|
| Presentation Project Idea | Customer presents a rough overview on the project, Pengutronix presents possible solutions. If there is a requirement specification, preparation of a budgetary offer. If not, support in preparation of a requirement specification (Consulting). |
| Planning Phase | Activities |
|---|---|
| Requirements Workshop | Customer presents project, discussion of all functional requirements, presentation of possible hard- and software solutions. Preparation of written minutes. |
| Requirement Specification and Functional Specification | Customer prepares requirement specification, Pengutronix prepares functional specification. Discussion of possible solutions and requirements. |
| Estimation and Order | Pengutronix prepares estimation as foundation for offer. Customer orders project. |
| Development Phase | Activities |
|---|---|
| Iteration 1 | Realisation of work packages by Pengutronix Kernel Team, documentation, delivery of results (via RCS), test and initial operation, if necessary adjustment of specifications. Mainlining of finished components. |
| Iteration 2...N | ... |
| Hand-off Phase | Activities |
|---|---|
| Acceptance | Joint acceptance of a release version. |
| Outlook | Discussion of further possible functionalities and development steps. |
More Information
- Contact: Robert Schwebel