Open Development Platform for Embedded Systems

0 Open Development Platform for Embedded Systems E. Ostúa, A. Muñoz, P. Ruiz-de-Clavijo, M.J. Bellido, D. Guerrero and A. Millán Grupo de Investigación y Desarrollo Digital (ID2) Dpto. Tecnología Electrónica, University of Seville Spain 1. Introduction Embedded systems are those that implement a specific function while satisfying a number of restrictions. These restrictions have evolved over time and today, the most common for this type of system are cost and low consumption, and minimum size and weight. Moreover, the demand for embedded systems for different functions, and also the complexity of these functions has increased significantly in recent years. Also, due to the high level of competition, is the need to significantly reduce development times of these systems (Sangiovanni-Vincentelli, 2001). All these problems in the design of embedded systems have been giving rise to an evolution in design methodology, so it has passed from implementing them as an application specific hardware, to a methodology whose main part is software design. This change in methodology has been possible thanks to advances in technology that allow a complete system to be included in a single chip (ie, System on Chip, SoC). The hardware architecture of Embedded systems in SoC technology consists of a microprocessor as a core, around which are the components or peripherals necessary to carry out the function of the system. This function is implemented through software running on the microprocessor (Beeckler, 2007; Atitallah, 2008). For views of both cost reduction as well as development time, design methodologies of embedded systems have consisted of pre-built hardware platforms closed with a wide range of applications. This range of applications is achieved because these platforms have multiple ports that are able to package different types of signals. The most common platforms of this type are microcontrollers (MCUs) and digital signal processors (DSPs). With this type of component, the final application design consists primarily in the development of software running on them. In order to reduce development times as well as being able to use these platforms in highly complex functions, manufacturers have made an effort in software development environments (Salewski, 2005). Thus, in recent years, the new MCUs are characterized by supporting several operating system because they provide a convenient way for software applications development. However, these type of closed platforms reduce the degree of freedom of the designer of embedded systems. This is so because the designer is not able to manipulate and adapt the 14 www.intechopen.com 2 Will-be-set-by-IN-TECH hardware to the specific application. This could lead to an improved final performance of the system. An alternative to closed hardware platforms is the use of FPGAs (Ostua, 2008; Muñoz, 2008; Eastman, 2005). The high capacity of integration, low cost on short runs, and high performance in terms of operating frequency and power consumption in FPGAs makes it possible to implement an entire microprocessor-based system in one of these programmable devices. This type of FPGA-based hardware platform has several advantages over closed platforms: • SoC design adapted to the specific needs of embedded systems • Ability to design and adapt the hardware components to specific application functionality, and include them in the SoC • Dynamic reconfiguration capability of the SoC (Williams, 2004) However, the use of FPGAs necessarily implies an effort to design the hardware architecture that makes the total development time of the system can be significantly higher than in the case of closed platforms. To make the design of embedded systems using a FPGA as central core of the system feasible, CAD tools are necessary to facilitate the construction of the hardware architecture quickly and efficiently. Indeed, nowadays, manufacturers are leveraging the SoC design tools on FPGAs and there is a level of competition for the best solution that combines both ease of construction of the complete architecture as the best performance of the final system implemented. Examples of these tools are, for example Xilinx EDK (Xilinx Inc., 2009), Altera ESD (Altera Inc., 2009), etc. But in addition to facilitating the development of the hardware architecture it is also necessary to facilitate software development. This is the point where there is greater difference between the MCUs and FPGAs. The new MCUs are characterized by supporting operating systems. The introduction of the operating system level in an embedded system allows these to be used in applications of high complexity. In contrast, microprocessors used in FPGAs, are only now beginning to support operating systems (Henkel, 2004) such as the case with petalinux MicroBlaze (Petalogix Inc., 2010), or projects to port Linux to Altera’s Nios (Altera Inc., 2010) or Lattice Mico32 (Lattice Inc., 2010). In this chapter, we present a platform hw / sw open in the sense that it is technologically independent, and that it is implementable in low-cost FPGAs that meets both of the main features mentioned above: CAD tools that facilitate the development of SoC hardware architecture and, above all, a software development methodology comparable to the methods used in standard PCs. The platform is based on the LEON3 processor (Gaisler, 2010) that implements the SPARC v8 architecture. The main advantage is that on this microprocessor a Debian Linux distribution (Debian, 2010) was implemented. Having not only a Linux operating system, but of all the components of a very mature distribution as Debian, gives rise to a great potential and easiness when developing software applications for embedded systems. In what follows we describe the platform, starting with the hardware architecture. Then we describe the implementation process of the Debian distribution. In the 4th section, we detail a general development methodology for any application based on this platform. We show the advantages of the platform on a specific example of embedded system consisting of a terminal unit for location and positioning. Finally, are summarized the main points of work. 312 Grid Computing – Technology and Applications, Widespread Coverage and New Horizons www.intechopen.com Open Development Platform for Embedded Systems 3 2. SoC hardware level As we mentioned before, we chose LEON3 synthesizable microprocessor, that implements a SPARC architecture. The main features of this microprocessor are described as follows: • The LEON3 32-bit core implements the full SPARC V8 standard • It uses big-endian byte ordering and has 32bit internal registers • It has 72 instructions in 3 different formats and 3 different instruction addressing modes (immediate, displacement and indexed) • Implements signed and unsigned multiply, divide and MAC operations and has a 7-stage pipeline instructions • Also implements Harvard Architecture with two separate instruction and data cache interfaces With final purpose in mind, Debian was chosen as the Linux distribution, since it has been adapted and compiled for many architectures such as x86 or SPARC v8 among other features. The microprocessor we want to use, must have the ability to run any of these sets of instructions and should be capable of running a Linux kernel 2.6 version. For this purpose, it requires some extra functional blocks, such as a memory management unit (MMU) and a floating point unit (FPU), and should be included within the microprocessor. Moreover, the whole system must provide a minimum number of other functional blocks that enable a proper operating system support. These blocks are an interrupt controller and a timers unit. On the other hand, support for system memory and an alternative to connecting a mass storage medium should be included. The developed SoC includes a mixed memory control block, which allows access to both FLASH memory and SDRAM memory. It’s memory map is assigned as follows: the lowest memory addresses point to the non-volatile memory, while the the rest of addresses cover the dynamic memory. In this way, the start of FLASH memory match the microprocessor boot vector, allowing one to store and run a boot loader in these positions. In order to provide disk space for the operating system, the inclusion of an IDE interface controller was a good option. This controller has been connected to a Compact Flash card and, in addition, this medium is also used to provide swap memory to the system. Finally, it is necessary to add some peripheral blocks for communication with the outside of the SoC. It is interesting to provide some kind of Internet access to fully exploit the advantages that the operating system as a development platform provides. Therefore, we have implemented both access methods: modem and Ethernet interfaces. It also includes other general-purpose and debug ports, such an UART blocks that provide RS232 communication. In summary, figure 1 shows the block-level diagram of the system, where all functional blocks that have been included can be appreciated. Its interconnections has been made through open AMBA 2.0 Bus specification. Most building blocks of this design are part of a set of libraries and IP cores (including LEON3 microprocessor) called Grlib (Gaisler, 2010). However, it is relatively easy to add new logic cores to the system. For example, a 16550 UART core have been added to support a modem GSM / GPRS communications. This core, wich is based on a model written in Verilog 313 Open Development Platform for Embedded Systems www.intechopen.com 4 Will-be-set-by-IN-TECH Fig. 1. SoC block-level diagram language, is obtained from Opencores (OpenCores, 2010). It was necessary do some work to adapt its native intefarce to function properly with the AMBA APB bus. The synthesis of this design can be accomplished with many software packages and may use different FPGA families and even ASIC as target. Grlib includes some shell scripts for Linux that greatly facilitate this task. In this chapter, the Xilinx ISE package (Xilinx Inc, 2010) has been used, obtaining the results of compilation and synthesis for Spartan3 XC1500 shown at table 1. These results are heavily dependent on the choices made when configuring the microprocessor. For example, the size of data and instructions caches, and the number and complexity of the peripherals that have been added to the system, will dramatically change these results. 3. SoC platform operating system The main objective of this chapter is aimed at obtaining a development platform similar to those available on conventional workstations, but this one will run on top of the SoC platform itself. To accomplish this, and based on the exclusive use of open software, we will install a complete Linux distribution, allowing the use of all development tools, compilers and libraries and also take advantage of using open source code without restrictions. We can divide our campaign into two main goals, as the SoC platform should first be able to boot a Linux kernel before a complete Linux distribution can be installed. The LEON3 core we 314 Grid Computing – Technology and Applications, Widespread Coverage and New Horizons www.intechopen.com Open Development Platform for Embedded Systems 5 Device Utilization Summary Number of BUFGMUXs 4 out of 8 50% Number of DCMs 2 out of 4 50% Number of LOCed DCMs 2 out of 2 100% Number of External IOBs 221 out of 333 66% Number of LOCed IOBs 192 out of 221 86% Number of MULT18X18s 1 out of 32 3% Number of RAMB16s 14 out of 32 43% Number of Slices 12809 out of 13312 96% Number of SLICEMs 391 out of 6656 5% Overall effort level (-ol): High Router effort level (-rl): High Timing summary Timing errors: 0 Score: 0 Constraints cover 21241138 paths, 0 nets and 106771 connections Design statistics Minimum period: 24.822ns Maximum frequency: 40.287MHz Minimum input required time before clock: 6.591ns Minimum output required time after clock: 12.193ns Table 1. Xilinx ISE compilation and synthesis planned to synthesize meets all the requirements for the implementation of a modern Linux kernel 2.6, while a few adaptations are necessary to meet the particularities of its architecture. 3.1 SnapGear & boot-loader Snapgear (SnapGear, 2010) is an open source specific Linux distribution for embedded systems. A fork of the main distribution was adapted by Gaisler Research for LEON3 systems, which have included various kernel patches and a few basic device drivers. This software package also includes a fundamental and indispensable element in order to load the operating system, which is the boot loader. This small piece of software is usually stored at the beginning of the FLASH memory which must correspond to the memory address $0, so it’s then executed by LEON3 processor on the startup process. The first function of the boot loader is to initialize the basic hardware system, such as debugging console or memory chips. Then it proceeds to uncompress the software package you want to run to the RAM memory system, both a 2.6 Linux kernel and a small romfs filesystem, both Gzipped. On this read-only file system the Linux kernel mounts the root system, which includes all utilities and applications that we have decided to include in the software applications compilation. 315 Open Development Platform for Embedded Systems www.intechopen.com 6 Will-be-set-by-IN-TECH Fig. 2. SoC Boot Up Another important ability of this small piece of software (boot loader) is to pass arguments to the Linux kernel, which avoids the need to use complex bootloaders such as LILO or GRUB, which are necessary in workstations. The configuration of the Linux kernel and boot loader and the preparation of the romfs unit are performed by a few scripts. After this process, we proceed to compile the software system and so a set of software images (object files) are obtained. With this set of object files generated we chose an image prepared for flash memory that contains the boot loader with the Linux kernel and the small romfs file system. Then we can program the flash memory using the Debug-Support Unit (DSU) within LEON3 core by interfacing with a JTAG or Ethernet connection, using the debugging application grmon from Gaisler Research. Once the process is completed we have a functional Linux kernel with very basic core lightweight applications on top of our SoC platform. The complete programming and booting process of the SoC platform is shown in figure 2. 316 Grid Computing – Technology and Applications, Widespread Coverage and New Horizons www.intechopen.com Open Development Platform for Embedded Systems 7 3.2 Debian Once Snapgear Linux operating system is running on the system it’s time to implement a complete Debian distribution, obtained directly from an official Debian repository. This distribution is precompiled for many platforms, including SPARC V8, which makes it mandatory to usage of Integer Multiplier (MUL) and a Floating Point Unit (FPU) hardware cores, which LEON3 provides. There are a few ways to install this operating system, however we have chosen the defacto approach to use a small application called debootstrap, which takes care of the download, unzip and install all necessary packages for our target platform. A file system was created that includes such romfs application and its dependencies to other libraries and applications (such as wget and binutils) and they were integrated into the image we created for Snapgear in the previous step. After the inclusion of the new file system in the romfs Snapgear compilation, it is possible to boot the Linux system and to prepare the installation process of the Debian distribution. In order to do so, having initialized the system and using the Linux shell, it proceeds to boot and configure the Ethernet interface to access the Internet and a DNS server. Then comes the setup for the drive where you want to install the operating system, which in this case it’s a portable solid state memory Compact Flash Card connected through an ATA Controller IP core, but also could have opted for a remote unit NFS hard disk drive IDE interface as a network booting solution. It is desirable to have at least 1.5 GBytes free on the device to allow easy installation of those software packages and also in order to make use of swap space. Next, two partitions are created in the disk, one for the ext2 filesystem and one swap, with the commands fdisk, mke2fs and mkswap, which are then assembled and activated by the commands mount and swapon. We must note that romfs is a read-only filesystem, so it has been necessary to have an empty path to mount the unit, in our case we have used the path /mnt/debinst. In this state, the system is ready to install Debian Operating System Cross. Simply run the setup application debootstrap like this: # /usr/sbin/debootstrap -arch sparc stable /mnt/debinst http://ftp.es.debian.org/debian This command starts downloading packages from the Internet repository. These software packages are stored in the mass storage unit, to be validated and then installed in the system. Once the process gets the basic installation of Debian on the drive, then it’s necessary to configure certain aspects before its first use. At this point the use of chroot command proved quite useful to facilitate the entire process of design and preparation. This command allows the change of the root environment file system and keep running applications of the new distribution in the path that has been installed, allowing one to continue the setup process without restarting the whole system. Firstly, the process was necessary to explicitly indicate the operating system to invoke a command line (shell) when booting the system (init process). To achieve this we simply 317 Open Development Platform for Embedded Systems www.intechopen.com 8 Will-be-set-by-IN-TECH modified the description file load during the boot process of the operating system, the file /etc/inittab, by adding the following line: T0: 234: respawn:/sbin/getty -L ttyS0 38400 vt100 Thus, the getty application launched a shell connected to the serial port every time the system restarts. Secondly, the network interface and the name servers (DNS) have to be configured in order to introduce a suitable network configuration, adjusting the files /etc/network/interfaces and /etc/resolv.conf . Also it’s need to tell where the mount points of the units will be, such as the boot, root and swap file systems. Like in other standard distributions, one just has to edit the configuration file /etc/fstab. Finally the /dev directory is empty in the new distribution installation and so it was necessary to create the block and character devices in order to let the kernel manage the peripherals, a task done using the mknod command. Once the installation and configuration of the Debian Linux distribution is complete, it’s time to recompile the kernel adapted to the LEON3 microprocessor. In this new compilation the romfs partition is removed and the kernel will take the parameters where to locate the actual root file system (the drives) by modifying the boot loader configuration. This argument was necessary to provide the kernel to configure the system console through the serial port and to tell the kernel where the root filesystem was: # console=ttyS0, 38400 root=/dev/hda1 Finally started, the system with the new kernel and the Debian Linux installation that, after loading, presented a console with all the benefits of this operating system. Importantly, once complete the whole process of installation and configuration, has the tools Debian APT package installation, such as apt-get, which allow you to install many libraries and applications, such as compilers, servers, internet services, daemons, desktop environments, etc., and even full distribution upgrades quickly and conveniently. 4. Developing methodology The previous sections have been devoted to describing the basic technical characteristics of the platform proposed. This section, however, is devoted to discuss the development methodology of embedded systems based on this platform. The developing methodology of SOCs is divided two main parts: hardware developing and software developing. Although both are interlaced, they are very different. With regard to hardware development, begin identifying the components needed for the specific embedded system will be implemented. These components will be the interface of the SoC with the ports needed by the system. Once identified, we must make the complete design of SoC (as shown in Figure 1) including all necessary components. As mentioned in section 2, this process will be done with GRLIB library that comes with the development system LEON3 processor. GRLIB includes a large number of components common in embedded systems. One of the advantages of this 318 Grid Computing – Technology and Applications, Widespread Coverage and New Horizons www.intechopen.com Open Development Platform for Embedded Systems 9 platform is the possibility of designing a controller or peripheral specific for a particular application, which can be included in the SoC. It is also possible to reuse IP cores available for other systems. In these cases, it will make a design interface with the AMBA bus, which is the main bus that uses the hardware platform. The most important improvement on this platform is under software developing since, the biggest effort in SOCs developing falls on the software and specifically in the interaction with peripherals. Our platform includes a operating system installed that solves the peripheral management through the device drivers. Even if a given driver is not avaliable for a new hardware, using Debian distribution we have tools to makes easy the developing. While with a conventional software developing methodology, some external tools are required: cross compilers, emulators, debug connection tools, etc., once installed the Debian distribution some advantages are achieved versus conventional software development methodologies of embedded systems. We have achived significant improvements in the software tasks such as installing, compiling and developing, also, in the manage of devices drives or in high level applications. All this due some advantages of the using Debian as base software, it can be summarized as following: • The Debian repositories has a large set of precompiled software that can be easily installed using the distribution tools. All is done inside of the platform without external tools. • The distribution provides a the development environment and integrated debug tools that may be installed inside the platform. Also, without the need of external tools. • Several improvements in the process of update firmware/software. The distribution adds tools to update all software installed inside in an automated mode. Usually, is not an easy task to install any precompiled software in a SoC. Most medium-high complex software applications depend of other software as shared libraries or external tools. Software distributions give tools to solve applications dependences. Specifically, the main feature of Debian software distribution is the Debian package machinery. This resolves the software dependencies and creates a minimal configuration for each installed software. This minimal configuration allows the putting services on just after install processes and also, can be used as example of end software configuration. Using precompiled software avoids the heavy task of compile software. Compile software for embeded systems is a heavy task due some of following reasons: one, is the dependence between applications and shared libraries making the compilation process complex. Usually one application needs an exact version of each required shared library. If there are several applications installed at the same time, the same library could appear several times, but with a different version number. In this situation install, upgrade and maintain the software is a tedious task. Other reasons that make the task of compile software for SoCs complex is the use of cross compilers to generate software. Once compiled software, to test it, all necessary files must be transferred and installed: executable files, shared libraries, config files, etc. The steps of compiling and transference are repeated as many times as necessary to achieve the software to be ready. This process is improved when the Debian distribution is installed. It is possible to install all compiler tools in the platform and make the compilation process inside of platform. Also, this task is assisted by Debian tools since, it detects all dependencies between 319 Open Development Platform for Embedded Systems www.intechopen.com © 2012 The Author(s). Licensee IntechOpen. This is an open access article distributed under the terms of the Creative Commons Attribution 3.0 License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.