The document discusses the use of Linux for embedded industrial project development, detailing its growth and advantages in the embedded market, including support for various architectures and performance benefits. It outlines typical projects, the transition from legacy real-time operating systems to Linux, and the challenges encountered during porting applications to Linux, specifically highlighting the need for real-time extensions for hard real-time requirements. Furthermore, it emphasizes the importance of source code access and the efficiency of Linux in embedded systems with quick boot times and tailored memory usage.

1. Using Linux for industrial projects Return of experience C. Charreyre

2. License Attribution-Noncommercial-Share Alike 2.0 France You are free: to Share - to copy, distribute, display, and perform the work to Remix - to make derivative works Under the following conditions: Attribution. You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work). Non commercial. You may not use this work for commercial purposes. Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one. For any reuse or distribution, you must make clear to others the license terms of this work. The best way to do this is with a link to this web page . Any of the above conditions can be waived if you get permission from the copyright holder. Nothing in this license impairs or restricts the author's moral rights.

3. CIO Informatique Industrielle Company dedicated to industrial software development Incorporated in 1990 15 engineers to help customers on embedded and real time software Great investment on Linux technologies since 2000 Competence center created in 2001 Located in St Etienne and Marseille Member of Libertis, association of free software service companies in PACA http://www.libertis.org

4. Linux on the embedded market Linux is a fast growing actor on the embedded market It is know representing about 50% of the market Source Embedded Linux Market Survey 2007 LinuxDevices.com

5. Linux on the embedded market The Arm processor is the most used architecture with Linux Linux + Arm is a great solution for low price mass market devices Source Embedded Linux Market Survey 2007 LinuxDevices.com

6. Linux at CIO Typical projects : Software developments for industrials or aerospace/defense With real time and embedded characteristics OS used until 2000 : Legacy RTOS like OS9, VxWorks, QNX etc.... Investment on Linux technologies in 2000 A step by step approach : Use of Linux distribution on PC (desktop, PC104, SBC, Compact PCI) Home made reduced Linux on same architecture Use of real time extensions to get same performances as legacy RTOS Use on other architectures used in projects : PowerPC, Arm We suggest such an approach to new adopters (from easiest to most difficult)

7. Linux for embedded device Requirements of embedded projects : Processor architecture can be Intel, but also PPC, Arm, microcontroller ... Linux available on many architectures used in embedded devices : X86, Freescale, Arm, SuperH, AVR32, Blackfin ... (24 arch. In 2.6.23) Low memory and storage requirements Linux distributions are huge (Gigabytes), and require Megabytes of memory The good approach is to build a reduced embedded image, with the precise requirements of the project By rebuilding a dedicated embedded image, one can reach sizes like 4 MB of mass storage and 8 MB of memory Flash support Compact Flash or Disk on Module emulate IDE, managed by IDE driver NAND or NOR flash managed by the MTD framework, with a lot of chipsets supported

8. Linux for embedded device Requirements of embedded projects : Quick boot Boot time = Bootloader (+ BIOS if X86) + Linux startup Bootloader must be tuned to reduce its time Linux startup can range from few seconds to few tens of seconds depending on processor speed and quantity of services, for embedded images Switch off without shutdown Journaling capabilities of Linux filesystems reduce risks, but are not sufficient in embedded world The solution is to use RAM disks as the root of the file system : in case of file system corruption, the copy in RAM is corrupted, not the file system itself With an adequate strategy, Linux can deal with the requirements of embedded devices

9. An embedded project Customer requirements : Complete access to source code Different hardware and form factor Performant and reliable TCP/IP stack Quick availability after power on

10. An embedded project Linux chosen because : Linux and basic components governed by GPL, the sources of the developed application itself were also given to the customer Linux available on first architectures (X86 on Compact PCI and PPC on VME) Linux TCP/IP stack are performant (most Web servers run under Linux) Very quick availability after power on thanks to very reduced dedicated image The project has been delivered successfully for the first 2 architectures, and it will be easy to swap to new ones The customer performs later evolutions by itself

11. Real time with Linux Types of project : Embedded only : Linux OK Soft real time : Linux OK with adapted strategy Hard real time : Linux not OK, but Linux + Real time extension OK Linux is a general purpose OS, the scheduler's mission is to distribute the processor to all processes on a fair base in a large time scale (no fixed priority). Soft real time is accessible through the scheduler API : « Real time » class implements same scheduling principles than RTOS There is no guarantee on interrupt reaction duration, due to the internal structure of kernel, so hard real time not possible Kernel 2.6 can be preemptible, but large sections of the kernel have interrupt masked or preemption disabled, so even 2.6 is not hard real time Preemptible kernel 2.6 + real time class scheduling  Soft real time

12. Real time with Linux Hard real time needs a real time extension : RTLinux : GPL, then commercial product, now bought by WindRiver RTAI : GPL Xenomai : GPL, skins available Extension implemented as kernel modules Extension implements a RTOS Application shared between Linux (not real time part) and extension (real time part) with IPC between the 2 worlds. In the real time part, no access to Linux system calls nor drivers (a real time driver framework : RTDM) Possibility to develop the real time part as : Full kernel modules Linux processes managed by the real time extension

13. A real time project The project is to develop a data recorder for high end automotives (to record data on vehicle's buses). The hardware is built with PC104 board, with CPU, CAN board and a DSP board. Real time requirements : precise time stamp of data, full determinism in exchanges between CPU and DSP Kernel 2.4 choosen, due to Linux drivers availability, and conservative approach when project was launched RTAI used for real time purposes CIO's job : Soft choices Linux + RTAI integration Port of Linux drivers towards RTAI Application skeleton development

14. Porting from RTOS to Linux Why porting from RTOS to Linux : Replacing old hardware by newest one, not yet supported by RTOS Avoiding licence costs .... To avoid important costs, it is interessant to port as much as possible at the OS level : System calls remapping Compatibility library The goal is to change the applications sources the less possible, to avoid development and revalidation costs A project example : port of a SNMP stack from 68K / OS9 towards PowerPC / Linux This port was a mock up for a larger application

15. Porting from RTOS to Linux Main difficulties encountered : Compiler change reveals problems in the original sources. Gnu chain makes much more control than original OS9 compiler : Quality problems in original sources, syntax errors .... Bad data alignment of structure members Consequence : a lot of unforeseen work to correct the sources Memory model : OS9 processes shared data structures : members of shared data were pointers No problem on OS9 with flat memory model Impossible with Linux with segmented memory through MMU Solved by using the shared memory API, with fixed mapping of the shared memory at same address for all processes Use of signals and alarms : Cooperation between OS9 process made with a lot of signals Linux offers very few signals available to users Development of an emulation API of OS signals based on SIGUSR1

16. Porting from RTOS to Linux Main difficulties encountered : Use of signals and alarms : A lot of alarms running in parallel in the original OS9 application Linux is not designed to have such an architecture Solved by developping an alarm emulation API based on dedicated alarm threads Other system aspects where quite easy to remap with wrappers (through include files) The port was finally achieved successfully. It demonstrated the concept could be extended to the whole application 3 types of difficulties : Relative easy remapping of system calls (the majority) More challenging points solved by emulation library (signals, alarms) Most difficult points : memory model and original sources difficulties triggered by compiler change.

17. More information Web site http://www.cioinfoindus.fr Contact us : Tél : +33 4 95 05 19 41 Mail : christian.charreyre@cioinfoindus.fr