Fedora Linux Kernels Running on ARM Processors

Transcription

1 Fedora Linux Kernels Running on ARM Processors PETER KOTVAN, PETER FODREK Institute of Control and Industrial Informatics Faculty of Electrical Engineering and Information Technology Slovak University of Technology Ilkovičova 3, Bratislava SLOVAK REPUBLIC Abstract: This paper will report our experience with installing and using the Fedora Linux distribution on a dedicated ARM processor based device. At first we will deal with ARM processors and its specifics. In the next section ARM based devices Dreamplug will be described. We will describe installation of Fedora Linux distribution on Dreamplug and compilation of the Linux kernel. The original Fedora kernel package was altered to support ARM based devices which incorporates different approaches especially to bootstrapping. Key Words: Fedora, Linux Kernel, ARM processors 1 Introduction ARM is a reduced instruction set computer processor architecture. It is the most widely used 32-bit instruction set architecture. The combination of high performance, low power consumption and low heat emission resulted in application of this architecture in mobile phones, PDAs, tablets and cameras. With implementation of multi-cored ARM processors, it is possible to use ARM based devices also for netbooks and small servers. Fedora is one of the many GNU/Linux distributions, operating systems that contain Linux kernel maintained by Linus Torvalds and GNU software collection developed by the Free software foundation founded by Richard Stallman. Fedora, a child system of Red Hat Enterprise Linux is based on an RPM packaging system. Different booting mechanisms, absence of BIOS and uboot bootloader on ARM devices are the most significant differences between x86 an ARM based devices. We take these differences into account and implement new features to Fedora kernel package to provide common Fedora package management for the kernel package also on the ARM machines. This paper intends to describe the specifics of ARM architecture and devices based on it and to provide a grasp of RPM packaging methods and routines, the creation and the installation of RPM packages. 2 ARM architecture and devices There are two main processor architectures used over the course of last years. Usually, a personal computer contains one of x86 or x86-64, however the most popular 32-bit architecture is ARM (Advanced RISC Machine). As the name says ARM is reduced instruction set computer (RISC). Currently ARM processors are used primarily in smart phones, tablets and embedded devices. In the future, it is likely that the computers will be, too, powered by these processors. Architectural simplicity allowed by RISC instruction set opened the way to small hardware implementations which allows for the manufacture of processors with very a low power consumption. The performance gain provided by RISC derives from the concept of simplicity that enables a significantly faster execution of each instruction. The heat produced can be absorbed by passive cooling. These features make ARM processors suitable for mobile and embedded systems. Typical RISC architecture features: large uniform register file a load/store architecture, where data processing operations only operate on register contents, not directly on memory contents uniform and fixed-length instruction fields, to simplify instruction decode. ARM also provides: auto-increment and auto-decrement addressing modes to optimize the program loops ISBN:

2 Load and Store Multiple instructions to maximize date throughput conditional execution of almost all instructions to maximize execution throughput. ARM has 31 general-purpose 32-bit registers. 16 of these registers are visible at any time, the other registers are used to speed up the exception processing. All of these 16 registers are the User mode registers. User mode, being unprivileged is different from other modes. One of the specifics of the User mode is that the memory systems and coprocessors may allow only partial access to memory and coprocessor functionality to the User mode than to a Privileged mode. Three of the User mode registers have special function, stack pointer, link register that holds the address of the next instruction following the Branch and Link instruction and a program counter used as a pointer to the instruction which is two instructions after the instruction being executed. 2.1 Devices Common ARM-based devices available on market are running mostly on Android, ios or Symbian operating systems. Both Android and ios belong to the Unix-like operating systems family. Apart from these closed-source devices there is also a number of opensource and development platforms like BeagleBoardxM, PandaBoard, Sheevaplug or Dreamplug. As the name indicates, the BeagleBoard and the PandaBoard are development boards with no case. Both devices have a video output (BeagleBoard S- video/dvi-d, PandaBoard HDMI) thus can function as a standard computer when a monitor, a keyboard and a mouse are connected. 2.2 Dreamplug Dreamplug in contrast to the two above-mentioned boards, is fully an end-product. It is manufactured by Globalscale technologies, INC. Dreamplug is a successor of Sheevaplug and Guruplug. These three devices are based on Marwell ARM processors and have similar hardware design. Sheevaplug, the simplest device has only one ethernet interface and one USB port. The absence of video output makes Dreamplug suitable for server applications such as web/ftp server or OpenVPN server. Making the advantage of two ethernet ports, WiFi and bluetooth with an external hard drive connected through USB or esata Dreamplug can be used as NAS (network attached storage) or as home media server. The newest product from Globalscale is D2Plug, successor of Dreamplug. In comparison with Dreamplug D2Plug has a VGA and a HDMI video output. Figure 1: Dreamplug The main components are [2]: 1.2GHz Marvell 88F6281 processor with Sheeva technology 2MB SPI NOR Flash for uboot Onboard 4GB microsd memory card 512MB SDRAM JTAG and UART connectors for development purposes. Peripherals: Two Gigabit Ethernet connectors Two USB 2.0 ports esata 2.0 port SD card socket WiFi: b/g/n Bluetooth EDR Analog audio output and input S/PDIF fiber optics interface for digital audio output In the following three sections we will discuss how ARM devices boot, the installation of operating system and the communication with these devices. ISBN:

3 2.3 Boot sequence and bootloader There is a significant difference between x86, x86-64 and ARM machines in booting up the device. Standard personal computers use BIOS (Basic Input Output System), software that is built into the computer and that is the first program run by PC after power up. BIOS is stored on a non-volatile ROM chip on the motherboard. After turning on the computer, BIOS initializes and identifies computer hardware such as CPU, RAM, video card, keyboard, mouse and hard discs. After this initialization, BIOS locates the bootloader stored on the hard disc or CD and executes it. At this moment, bootloader gains control over the computer. Common bootloaders used on Linux systems are LILO (LInux LOader) and GNU GRUB (GNU GRand Unified Botloader). ARM devices do not include BIOS and different devices can bootstrap in a different way. Most common bootloader used for ARM on open-source devices is Das U-Boot (The Universal Boot Loader). uboot is typically stored on a small NAND or NOR non-volatile memory chip on the board or on a µsd card. The purpose of this flash storage can differ. In case of the Dreamplug there is a 2MB SPI NOR flash storage that stores uboot binary and its configuration data and the root file system. In contrast, BeagleBoard or BeagleBoard-xM employ larger storages that hold also the kernel binary. 2.5 Installation Dreamplug is originally shipped with the Ubuntu Linux operating system. Typical Linux installation procedure involves downloading the installation media from a web page of a particular distribution, burning it on a CD or a DVD media and after booting from it, the installation can be performed. The main reasons why there is not a universal installer for Fedora ARM are significant hardware differences between ARM platforms especially considering location of kernel and between different version of uboot bootloader installed. However Fedora ARM development team is considering development of such a universal installer for ARM devices. Installation of a Fedora distribution was necessary to access Fedora specific package management and building tools. After disassembling Dreamplug the micro SD card was unmounted. uboot can read kernel image only from the first partition on the SD card that has to be formatted to fat. Root file system is stored on another partition. After the formatting into ext3 standard Linux file system the installation itself consists of extracting precompiled root file system downloaded from Fedora ARM website to the SD card. [3] 2.6 Communication with Dreamplug 2.4 uboot on Dreamplug After powering up Dreamplug uboot is loaded into memory and executed: U Boot g8f495d9 d i r t y Marvell DreamPlug SoC : Kirkwood 88 F6281 A0 DRAM: 512 MiB SF : D e t e c t e d MX25L1606 with page s i z e 256, t o t a l 1 MiB In : s e r i a l Out : s e r i a l E r r : s e r i a l Net : egiga0, e g i g a 1 88 E1121 I n i t i a l i z e d on e g i g a 0 88 E1121 I n i t i a l i z e d on e g i g a 1 H i t any key t o s t o p a u t o b o o t : 0 Marvell>> Direct communication with Dreamplug can be established with JTAG module through a uart (universal asynchronous receiver/transmitter) interface. Uart takes data bytes and transmits the individual bits sequentially. At the destination, a second uart reassembles the bits into bytes. Serial transmission is mostly used for non-networked communication between computers and terminals. For communication over uart we can use minicom, serial communication software. After connecting Dreamplug to the network via ethernet interface and configuring network connection it is possible to establish connection with ssh remote secure shell. Short information summary about the device is printed into terminal. In uboot console it is possible to change the bootloader settings or select the boot device manually. Beside booting from internal SD card or device connected with USB or esata it is possible to load kernel via network using TFTP or RARP protocol. 3 The.spec file.spec file provides information on how to create the RPM package from SRPM with rpmbuild. In the following sections, the structure of the.spec file and actual kernel.spec modified for kernel package used with the Dreamplug will be described. ISBN:

4 % specdir - /rpmbuild/specs: RPM.spec files Figure 2: JTAG communication module with UART interface connected to Dreamplug 3.1 Structure of the.spec file The spec file is essential for building an RPM package. It contains macro definitions and scripts to specify the package build and installation. To build both the source and the binary packages rpmbuild -ba NAME.spec has to be executed in /rpmbuild/specs directory. rpmbuild then run through six stages defined in the.spec file (names beginning with % are predefined macros): %prep reads the sources and patches from the source directory % sourcedir, extracts them to the build directory% builddir and applies the patches. %build compiles the files stored in the % builddir. This is typically implemented by running./configure script and make. %check tests if the software runs correctly. Packages mostly do not implement this stage. %install reads the files from % builddir and writes to a % buildrootdir. Files located in the build root directory are files to be installed when the binary package is installed by user. This process is typically implemented by make install. bin reads the files from% buildrootdir to create binary RPM package in% rpmdir. In the RPM directory, there are subdirectories for each architecture, and a noarch directory for packages that can be installed on every architecture. src creates the source RPM package inside the % srcrpmdir. Macros ending with dir specify directories with special purpose [1]: % sourcedir - /rpmbuild/sources: source tarballs and patches % builddir - /rpmbuild/build: unpacked and compiled sources % buildrootdir - /rpmbuild/buildroot: files used during installation % rpmdir - /rpmbuild/rpms: binary RPMs % srcrpmdir - source RPMs. /rpmbuild/srpms: In the following section, we will describe all of the kernel.spec file stages and changes made to enable the direct installation of kernel on devices based on Marvell Kirkwood processors, for example Dreamplug and Sheevaplug. 3.2 kernel.spec The kernel.spec file starts with macro definitions of kernel version, subpackages, architectures and their specific settings, dependencies, sources and patches. After defining the package version, the subpackages definition follows. Apart from the basic kernel, subpackages with kernel debug information, kernel documentation and C headers also with subpackages with special configuration as ARM OMAP, for all supported architectures are here defined. To create a new kirkwood subpackage we had to add it to the subpackage definitions. The f o l l o w i n g b u i l d o p t i o n s a r e e n a b l e d by d e f a u l t. s t a n d a r d k e r n e l %d e f i n e w i t h u p %{? w i t h o u t u p : 0} %{?! w i t h o u t u p : 1} k e r n e l debug %d e f i n e w i t h d e b u g %{? w i t h o u t d e b u g : 0} %{?! w i t h o u t d e b u g : 1} k e r n e l doc %d e f i n e with omap %{? w i t h o u t o m a p : 0} %{?! w i t h o u t o m a p : 1} k e r n e l kirkwood ( only v a l i d f o r arm ) %d e f i n e w i t h k i r k w o o d %{? w i t h o u t k i r k w o o d : 0} %{?! w i t h o u t k i r k w o o d : 1} The final build of particular package runs in koji server dedicated to one particular architecture. %ifnarch macros are used inkernel.spec to specify which subpackages ought to be built on particular architecture. Value of this macro is TRUE, if the build is running on a different architecture as is specified in the %infnarch parameters. ISBN:

5 omap i s only b u i l t on armv7 hard and s o f t f p %i f n a r c h armv7hl armv7l %d e f i n e w i t h t e g r a 0 %d e f i n e with omap 0 %d e f i n e with imx 0 %d e f i n e w i t h h i g h b a n k 0 k e r n e l kirkwood i s only b u i l t f o r armv5 %i f n a r c h a r m v 5 t e l %d e f i n e w i t h k i r k w o o d 0 As we can see, the kernel-kirkwood will be built only on armv5tel architectures. The special options for particular subpackage and architecture are also defined in this part of.spec file. A kernel image file is typically stored in /boot directory as a raw binary called vmlinuz or compressed to zimage with LZMA algorithm. Dreamplug and other ARM based devices with uboot bootloader use uimage, generated with make uimage. %i f a r c h %{arm} %d e f i n e a l l a r c h c o n f i g s k e r n e l %{v e r s i o n} arm. c o n f i g %d e f i n e i m a g e i n s t a l l p a t h boot %d e f i n e asmarch arm %d e f i n e h d r a r c h arm %d e f i n e m a k e t a r g e t uimage %d e f i n e k e r n e l i m a g e a r c h / arm / boot / uimage and missing sources are made. After these checks, the kernel sources are unpacked and patched, and the configuration files are created with make and merge.pl. The %build stage includes BuildKernel() shell function to execute the whole kernel building and installation process determined by the specific kernel variant. Since we cannot update uboot configuration stored on Dreamplugs NOR flash, we have to insert kirkwood specific installation. We assume that uboot always boots the uimage, thus the old kernel must be overwritten. The actual building is performed by running the BuildKernel() function: p r e p a r e d i r e c t o r i e s rm r f $RPM BUILD ROOT mkdir p $RPM BUILD ROOT / boot mkdir p $RPM BUILD ROOT%{ l i b e x e c d i r} cd l i n u x %{f a k e v e r s i o n}.%{ t a r g e t c p u} %i f %{w i t h k i r k w o o d} B u i l d K e r n e l %m a k e t a r g e t %k e r n e l i m a g e kirkwood The %install section of the.spec file includes directives for specific kernel subpackages and install scripts. After architecture specific options general requirements for kernel build are defined as package conflicts and prerequisites. The Provides: tag specifies list of package names provided by kernel source package. Build time dependencies are specified with the BuildRequires: tag. In order to create uimage kernel image we need to add uboot-tools package to the dependencies. L i s t t h e p a c k a g e s used d u r i n g t h e k e r n e l b u i l d B u i l d R e q u i r e s : p a t c h >= , bash >= , t a r B u i l d R e q u i r e s : bzip2, gzip, p e r l, make >= B u i l d R e q u i r e s : gcc >= , b i n u t i l s >= B u i l d R e q u i r e s : net t o o l s B u i l d R e q u i r e s : xmlto, a s c i i d o c %i f %{w i t h k i r k w o o d} B u i l d R e q u i r e s : uboot t o o l s The sources and patches stored in% sourcedir are specified with SourceX: and PatchX: where the X denotes the number of the source or patch file if package contains more of them. Source0: contains the full URL for the compressed archive containing the original upstream kernel source code. The last part of the.spec file before the%prep section contains the definitions of kernel packages and variants for all architectures with their descriptions. At the beginning of %prep section of the kernel.spec file, sanity checks for file conflicts 4 Conclusion We have successfully implemented changes to kernel.spec to enable compilation and installation on Marvell Kirkwood based devices (Dreamplug, Sheevaplug and Guruplug). Building of the kernel package was performed with rpmbuild and also with koji. The actual installation on Dreamplug was also succesful. Acknowledgements: The research was supported by Slovak University of Technology and Red Hat, Inc. Brno. This work was supported by the Slovak Research and Development Agency under contract No. VMSP-II References: [1] How to create an RPM package, http: //fedoraproject.org/wiki/how_to_ create_an_rpm_package, 30. Aug [2] DreamPlug - DevKit, globalscaletechnologies.com/ p-54-dreamplug-devkit.aspx, 30. Aug [3] Architectures/ARM/Kirkwood, https: //fedoraproject.org/wiki/ Architectures/ARM/Kirkwood, 30. Aug ISBN: