Faculty of Computer Science Chair for Real Time Systems Diploma Thesis Porting DotGNU to Embedded Linux Author: Alexander Stein Supervisor: Jun.-Prof. Dr.-Ing. Robert Baumgartl Dipl.-Ing. Ronald Sieber Date of Submission: May 15, 2008 Alexander Stein Porting DotGNU to Embedded Linux Diploma Thesis, Chemnitz University of Technology, 2008 Abstract Programming PLC systems is limited by the provided libraries. In contrary, hardware-near programming needs bigger eorts in e. g. initializing the hardware. This work oers a foundation to combine advantages of both development sides. Therefore, Portable.NET from the DotGNU project has been used, which is an im- plementation of CLI, better known as .NET. The target system is the PLCcore- 5484 microcontroller board, developed by SYS TEC electronic GmbH. Built upon the porting, two variants to use interrupt routines withing the Portabe.NET runtime environment have been analyzed. Finally, the reaction times to occuring interrupt events have been examined and compared. Die Programmierung für SPS-Systeme ist durch die gegebenen Bibliotheken beschränkt, während hardwarenahe Programmierung einen gröÿeren Aufwand durch z.B. Initialisierungen hat. Diese Arbeit bietet eine Grundlage, um die Vorteile bei- der Entwicklungsseiten zu kombinieren. Dafür wurde Portable.NET des DotGNU- Projekts, eine Implementierung des CLI, bekannter unter dem Namen .NET, be- nutzt. Das Zielsystem ist das PLCcore-5484 Mikrocontrollerboard der SYS TEC electronic GmbH. Aufbauend auf der Portierung wurden zwei Varianten zur Ein- bindung von Interrupt-Routinen in die Portable.NET Laufzeitumgebung untersucht. Abschlieÿend wurden die Reaktionszeiten zu eintretenden Interrupts analysiert und verglichen. Acknowledgements I would like to thank some persons who had inuence and supported me in my work. At rst, I want to thank my supervisors, Jun.-Prof. Dr.-Ing. Robert Baumgartl and Dipl.-Ing. Ronald Sieber, who passed many valuable comments to me. I am grateful to SYS TEC electronic GmbH for making this diploma thesis possible. Special thanks go to the developers of Portable.NET, who helped me to understand the internals of the program and to nd solutions for problems that occured in the course of my work. Last but not least, I want to thank my familiy that supported me in their special manner. Without their support, my study would not have been possible this way. Contents List of Tables iv List of Figures v Listings vi 1 Introduction 1 1.1 Objective . 1 1.2 Structure . 2 2 State of the Art 3 2.1 .NET Framework . 3 2.1.1 Common Language Runtime . 4 2.1.2 Common Type System . 6 2.1.3 Common Language Specication . 6 2.1.4 Common Intermediate Language . 7 2.1.5 Metadata . 8 2.1.6 .NET Class Library . 8 2.2 DotGNU . 9 2.2.1 Hans-Boehm Garbage Collector . 10 2.2.2 Foreign Function Interface . 11 2.2.3 Interpreter . 11 2.2.4 Unrolled Assembler Code . 12 2.2.5 JIT Support . 13 2.2.6 Debugging . 14 2.2.7 X11 Support . 16 2.2.8 Embedded Engine . 16 2.3 Mono . 17 i Contents 2.4 Rotor . 17 2.5 Coldre vs. m68k . 17 2.5.1 Exclusive Instructions . 18 2.5.2 Floating Point Size . 18 2.5.3 Other Dierences . 19 2.5.4 ABI Changes . 19 3 Implementation 20 3.1 Incompatible m68k Code . 20 3.2 Incompatible Alignments . 21 3.3 Broken Toolchain . 24 3.4 Unrolling Assembler Code . 24 3.4.1 Setup of the Unroller . 25 3.4.2 Unroller Implementation . 26 3.4.3 m68k Specics . 27 3.4.4 Macro Counting . 28 3.4.5 Extended Testsuite . 29 3.4.6 Floating Point Remainder . 34 3.4.7 Big Endianess . 34 3.4.8 NOP is not just no Operation . 35 3.4.9 Caches . 36 3.5 C# Debugging . 37 3.6 Interrupt Access in C# . 38 3.6.1 Kernel Module . 39 3.6.2 C# Application . 40 3.7 Results . 42 4 Performance 43 4.1 Portable.NET Benchmark . 43 4.2 Benchmark Results . 44 4.3 Interrupt Response Time . 46 5 Final Remarks and Further Work 53 5.1 Conclusion . 53 5.2 Improvements . 53 ii Contents 5.2.1 Increasing Engine Performance . 53 5.2.2 Tweaking IRQ Handling . 54 5.2.3 Porting JIT to MCF5484 . 55 5.2.4 Miscellaneous . 55 6 Acronyms 56 Bibliography 58 A Contents of the enclosed CD 61 iii List of Tables 2.1 New Instructions introduced on Coldre . 18 3.1 List of mentioned assembler instructions in this chapter . 22 4.1 Results from pnetmark for the dierent engines . 45 4.2 Comparisons to the interpreter engines . 50 iv List of Figures 2.1 Reduced compiler-ISA-combinations, adopted from [1] . 5 2.2 Relationship between CLS and CTS, adopted from [1] . 7 2.3 Development using pnet, adopted from [11] . 14 2.4 Debug Communication in Portable .NET . 15 3.1 IRQ access setup . 41 4.1 IRQ timings at 100 Hz rate . 48 4.2 IRQ timings at 10 Hz rate . 49 4.3 IRQ timings at 1 Hz rate . 50 4.4 IRQ timings at 0.1 Hz rate . 51 v Listings 3.1 Test and Set for m68k (adopted from pnet) . 20 3.2 Testcode for missing load_memindex macros . 31 3.3 Testcode for missing oating point macros . 31 3.4 Testcode for missing unsigned div instruction . 32 vi 1 Introduction SYS TEC electronic GmbH1 has developed a microcontroller board named PLCcore- 5484, which is based on the 32-bit Freescale MCF5484 microcontroller. This Programmable Logic Controller (PLC) core module is used industrially for the au- tomation of processes. Programming PLCs is limited by the system libraries, which are provided by the manufacturer. Thus, it is not possible to access hardware components or to react directly on interrupt events, unlike embedded programming using C or Assembler. However, it is desirable to combine the advantages like comfort of PLC programming and the exibility of hardware-near programming. Additionally, disadvantages of either sides should be eliminated, e. g. explicit hardware initializing in hardware- near programming or restricted type casts in PLC programs. 1.1 Objective This work shall build the foundation to make the above mentioned features possible. Therefore, a .NET runtime, actually the opensource implementation DotGNU, is used. DotGNU is suitable for the embedded Linux in PLCcore-5484, because it allows the wanted exibility and hardware access, which is required for realizing real time systems. Furthermore, this runtime also provides a class library for abstraction and encapsulation of details, like it is commonly used in PLC programming. Porting DotGNU to the MCF5484 microcontroller has to be done at rst. Afterwards, the possibilities of interrupt routine usage have to be analyzed and implemented. 1http://www.systec-electronic.com 1 1 Introduction 1.2 Structure The diploma thesis is divided into ve chapters. The rst section, the introduction, explains the backgrounds and objectives of this work. State of the art, the second chapter, outlines technologies and architectures related to the porting of DotGNU to embedded Linux. The next chapter, the implementation, describes the actual porting, as well as encountered problems and their solutions. This part also includes the realization of interrupt access inside DotGNU and the results of the entire im- plementation. The second last chapter contains information about performance of the runtime engine and response times from external interrupts. The nal chapter summarizes this paper and states ideas for further work. 2 2 State of the Art 2.1 .NET Framework This section gives an overview about .NET and its features. For more information about this framework [8], [1], [19], [17] and [11] are recommended. .NET is a programming platform developed by Microsoft. It is designed indepen- dently of the platform and operating system and standardized as ECMA international standard 335, which became accepted as an ISO standard later. The ocial name is Common Language Interface (CLI). Generally, it is possible to write every program using the .NET framework, but this does not hold true for drivers. The large programming library makes it easier to create an application, but in most cases it is just a wrapper for the Win32 API. There is also support for commonly used technologies and protocols, e. g. HTTP, XML, SOAP. This provides a unied set of features on every computer using a specic version of the .NET. So, all applications have the same features in the runtime like code checking, threading, garbage collection and exception handling. It is designed to be robust and secure. There are two dierent security models: Role- Based Security and Code Access Security. The rst one is the typical setup: several roles are dened, which have a dierent set of rights to access ressources on the running system. A program executed by a user automatically gets all the rights the user has. Using the second method, the rights granted that way may also be reduced. The security manager maps the security policy and the evidence (e. g. source, author) of the running assembly into a permission set assigned to the assembly. Accessing a ressource is restricted by a permission object, which checks the permission set of the assembly, if access is allowed. This is done for all assemblies in the current calling stack and for the actual access. The rights do not have to be restricted by 3 2 State of the Art any assembly. Combined with signed assemblies, an assembly replacement may be noticed, which could deny access for malicious code. The installation is easier than before as a program can be installed by copying the necessary les to the wanted directory. Consequentially, the deinstallation is just as easy. Removing the application directory is enough.