sign in sign up
<<
Home , DreamPlug, GuruPlug, SheevaPlug, Symbian

Latest Trends in Information Technology

Fedora 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 Ilkovicovaˇ 3, 812 19 Bratislava SLOVAK REPUBLIC [email protected], [email protected]

Abstract: This paper will report our experience with installing and using the Fedora Linux distribution on a dedi- cated 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 . 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 2 ARM architecture and devices There are two main processor architectures used over the course of last years. Usually, a personal computer ARM is a reduced instruction set computer processor contains one of or x86-64, however the most pop- architecture. It is the most widely used 32-bit instruc- ular 32-bit architecture is ARM (Advanced RISC Ma- tion set architecture. The combination of high perfor- chine). As the name says ARM is reduced instruction mance, low power consumption and low heat emis- set computer (RISC). Currently ARM processors are sion resulted in application of this architecture in mo- used primarily in smart phones, tablets and embedded bile phones, PDAs, tablets and cameras. With imple- devices. In the future, it is likely that the computers mentation of multi-cored ARM processors, it is possi- will be, too, powered by these processors. ble to use ARM based devices also for netbooks and Architectural simplicity allowed by RISC instruc- small servers. tion set opened the way to small hardware implemen- tations which allows for the manufacture of proces- Fedora is one of the many GNU/Linux distri- sors with very a low power consumption. The perfor- butions, operating systems that contain Linux ker- mance gain provided by RISC derives from the con- nel maintained by Linus Torvalds and GNU software cept of simplicity that enables a significantly faster ex- collection developed by the foundation ecution of each instruction. The heat produced can founded by Richard Stallman. Fedora, a child sys- be absorbed by passive cooling. These features make tem of Red Hat Enterprise Linux is based on an RPM ARM processors suitable for mobile and embedded packaging system. systems. Typical RISC architecture features: Different booting mechanisms, absence of BIOS • and uboot bootloader on ARM devices are the most large uniform register file significant differences between x86 an ARM based • a load/store architecture, where data processing devices. We take these differences into account and operations only operate on register contents, not implement new features to Fedora kernel package to directly on memory contents provide common Fedora package management for the kernel package also on the ARM machines. • uniform and fixed-length instruction fields, to simplify instruction decode. This paper intends to describe the specifics of ARM also provides: ARM architecture and devices based on it and to pro- vide a grasp of RPM packaging methods and routines, • auto-increment and auto-decrement addressing the creation and the installation of RPM packages. modes to optimize the program loops

ISBN: 978-1-61804-134-0 38 Latest Trends in Information Technology

• Load and Store Multiple instructions to maxi- The newest product from Globalscale is D2Plug, mize date throughput successor of Dreamplug. In comparison with Dream- plug D2Plug has a VGA and a HDMI video output. • 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 process- ing. All of these 16 registers are the User mode regis- ters. 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 to memory and coproces- sor functionality to the User mode than to a Privi- leged mode. Three of the User mode registers have special function, stack pointer, link register Figure 1: Dreamplug that holds the address of the next instruction follow- ing the Branch and Link instruction and a program The main components are [2]: counter used as a pointer to the instruction which is two instructions after the instruction being executed. • 1.2GHz Marvell 88F6281 processor with Sheeva technology

2.1 Devices • 2MB SPI NOR Flash for uboot Common ARM-based devices available on market are • running mostly on Android, iOS or oper- Onboard 4GB microSD memory card ating systems. Both Android and iOS belong to the Unix-like operating systems family. Apart from these • 512MB SDRAM closed-source devices there is also a number of open- source and development platforms like BeagleBoard- • JTAG and UART connectors for development xM, PandaBoard, Sheevaplug or Dreamplug. purposes. As the name indicates, the BeagleBoard and the PandaBoard are development boards with no case. Peripherals: Both devices have a video output (BeagleBoard S- video/DVI-D, PandaBoard HDMI) thus can function • Two Gigabit Ethernet connectors as a standard computer when a monitor, a keyboard and a mouse are connected. • Two USB 2.0 ports

• eSATA 2.0 port 2.2 Dreamplug • Dreamplug in contrast to the two above-mentioned SD card socket boards, is fully an end-product. It is manufactured by Globalscale technologies, INC. Dreamplug is a suc- • WiFi: 802.11 b/g/n cessor of Sheevaplug and Guruplug. These three de- vices are based on Marwell ARM processors and have • 2.1 + EDR similar hardware design. Sheevaplug, the simplest de- vice has only one ethernet interface and one USB port. • Analog audio output and input The absence of video output makes Dreamplug suitable for server applications such as web/ftp server • S/PDIF fiber optics interface for digital audio or OpenVPN server. Making the advantage of two output ethernet ports, WiFi and bluetooth with an external hard drive connected through USB or eSATA Dream- In the following three sections we will discuss plug can be used as NAS (network attached storage) how ARM devices boot, the installation of operating or as home media server. system and the communication with these devices.

ISBN: 978-1-61804-134-0 39 Latest Trends in Information Technology

2.3 Boot sequence and bootloader 2.5 Installation

There is a significant difference between x86, x86-64 Dreamplug is originally shipped with the and ARM machines in booting up the device. Stan- Linux . Typical Linux installation dard personal computers use BIOS (Basic Input Out- procedure involves downloading the installation me- put System), software that is built into the computer dia from a web page of a particular distribution, burn- and that is the first program run by PC after power ing it on a CD or a DVD media and after booting up. BIOS is stored on a non-volatile ROM chip on the from it, the installation can be performed. The main motherboard. After turning on the computer, BIOS reasons why there is not a universal installer for Fe- initializes and identifies computer hardware such as dora ARM are significant hardware differences be- CPU, RAM, video card, keyboard, mouse and hard tween ARM platforms especially considering location discs. After this initialization, BIOS locates the boot- of kernel and between different version of uboot boot- loader stored on the hard disc or CD and executes loader installed. However Fedora ARM development it. At this moment, bootloader gains control over team is considering development of such a universal the computer. Common bootloaders used on Linux installer for ARM devices. systems are LILO (LInux LOader) and GNU GRUB Installation of a Fedora distribution was neces- (GNU GRand Unified Botloader). sary to access Fedora specific package management ARM devices do not include BIOS and different and building tools. After disassembling Dreamplug devices can bootstrap in a different way. Most com- the micro SD card was unmounted. uboot can read mon bootloader used for ARM on open-source de- kernel image only from the first partition on the SD vices is Das U-Boot (The Universal Boot Loader). card that has to be formatted to fat. Root file system uboot is typically stored on a small NAND or NOR is stored on another partition. After the formatting non-volatile memory chip on the board or on a µSD into ext3 standard Linux file system the installation card. The purpose of this flash storage can differ. In itself consists of extracting precompiled root file sys- case of the Dreamplug there is a 2MB SPI NOR flash tem downloaded from Fedora ARM website to the SD storage that stores uboot binary and its configuration card. [3] data and the root file system. In contrast, BeagleBoard or BeagleBoard-xM employ larger storages that hold also the kernel binary. 2.6 Communication with Dreamplug

Direct communication with Dreamplug can be es- 2.4 uboot on Dreamplug tablished with JTAG module through a uart (univer- sal asynchronous receiver/transmitter) interface. Uart After powering up Dreamplug uboot is loaded into takes data bytes and transmits the individual bits se- memory and executed: quentially. At the destination, a second uart re-

U−Boot 2011.06−02334− g8f495d9−d i r t y assembles the bits into bytes. Serial transmission is Marvell−DreamPlug mostly used for non-networked communication be- tween computers and terminals. For communication SoC: Kirkwood 88F6281 A0 minicom DRAM: 512 MiB over uart we can use , serial communication SF: Detected MX25L1606 with page size 256, total 1 MiB software. In : s e r i a l After connecting Dreamplug to the network via Out : s e r i a l E r r : s e r i a l ethernet interface and configuring network connection Net: egiga0, egiga1 it is possible to establish connection with ssh remote 88E1121 Initialized on egiga0 secure shell. 88E1121 Initialized on egiga1 Hit any key to stop autoboot: 0 Marvell>>

Short information summary about the device is 3 The .spec file printed into terminal. In uboot console it is possible to change the bootloader settings or select the boot de- .spec file provides information on how to create the vice manually. Beside booting from internal SD card RPM package from SRPM with rpmbuild. In the fol- or device connected with USB or eSATA it is possi- lowing sections, the structure of the .spec file and ble to load kernel via network using TFTP or RARP actual kernel.spec modified for kernel package protocol. used with the Dreamplug will be described.

ISBN: 978-1-61804-134-0 40 Latest Trends in Information Technology

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

ISBN: 978-1-61804-134-0 41 Latest Trends in Information Technology

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

ISBN: 978-1-61804-134-0 42