DOCSLIB.ORG

Managing a Real-Time Embedded Linux Platform with Buildroot J

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Managing a Real-Time Embedded Linux Platform with Buildroot J WEPGF096 Proceedings of ICALEPCS2015, Melbourne, Australia MANAGING A REAL-TIME EMBEDDED LINUX PLATFORM WITH BUILDROOT J. Diamond#, K. Martin, FNAL*, Batavia, IL 60510, U.S.A. Abstract Developers of real-time embedded software often need LINUX “FROM SCRATCH” to build the operating system, kernel, tools and supporting The Linux from Scratch website [5] was chosen as the applications from source to work with the differences in model for the attempt to build a custom Linux platform their hardware configuration. The first attempts to from source. Linux from Scratch is an on-line resource introduce Linux-based real-time embedded systems into that explains in step-by-step fashion how to build an the Fermilab accelerator controls system used this entire Linux operating system from source. First the user approach but it was found to be time-consuming, difficult partitions the target’s disk on the build system. Then the to maintain and difficult to adapt to different hardware necessary source packages (about three dozen) and configurations. Buildroot is an open source build system patches (another dozen) are downloaded onto the build with a menu-driven configuration tool (similar to the system and unpacked into a special “chroot environment”. Linux kernel build system) that automates this process. A Then the toolchain packages are built and installed – not a customized Buildroot [1] system has been developed for trivial task in its own right. The toolchain is then used to use in the Fermilab accelerator controls system that build a complete Linux system from inside of the chroot includes several hardware configuration profiles environment - kernel, boot-loader, shell, etc. Once the (including Intel, ARM and PowerPC) and packages for system is in place the boot-scripts are installed and Fermilab support software. A bootable image file is configured. Finally, the boot-loader is installed on the produced containing the Linux kernel, shell and target CF disk and an attempt is made to boot the target supporting software suite that varies from 3 to 20 (things rarely work on the first try). megabytes large – ideal for network booting. The result As illustrated above, the process is exhausting and can is a platform that is easier to maintain and deploy in take several days to complete. It should be noted that the diverse hardware configurations. target platform was x86 so a cross-compile toolchain was not attempted (ARM targets came later). Once developed INTRODUCTION the root filesystem could be used to boot any target with a Scientific Linux [2] is a Linux distribution produced by similar hardware architecture. a collaborate effort between Fermilab, CERN and other The root filesystems produced with this method were in members of the global Linux community. Scientific the range of two to three hundred megabytes. One Linux has been used successfully as a target platform for significant drawback is that a boot image of this size is data acquisition in the Fermilab accelerator control still too large to network boot. The decision was made to system but only on commodity PC hardware and not with store the kernel, boot-scripts and network configuration real-time extensions [3]. When attempting to adopt on a Compact Flash (CF) disk installed with each target Scientific Linux to a real-time embedded application node and the root filesystem on a common network some road-blocks were encountered. The first was that filesystem that could be mounted by each target at boot Linux is not designed to be a hard real-time operating time. The network filesystem also contains the system. There are however, several options for making application programs, libraries and data areas. Linux real-time and all of these options require a custom One issue that was noticed early on was the failure rate kernel be built. At Fermilab, one route chosen was to use of the CF disks. CF disks are susceptible to failure after the Real-Time Application Interface (RTAI) [4]. The next many write-cycles. As noted above, application data is road-block was the minimum foot-print of the installed written to a network filesystem instead of the CF disk. To system. The minimum Scientific Linux install profile reduce the CF write cycles the /tmp and /log partitions requires 1.5GB of storage. This is a concern because it is were moved to a RAM disk and the system log was desirable to network boot the targets. The requirement for redirected to a syslog server. These efforts were able to a network boot capability drastically reduces the mitigate the failure rate of the CF disks. acceptable footprint size as the entire boot image needs to Another significant challenge with this platform was be transferred over the network. Finally, Scientific Linux maintainability. Installing new software packages in the is a binary distribution targeted for x86 architecture, thus root filesystem was easy but deploying to targets already it would not be possible to use as a platform for ARM and in the field meant physically replacing the CF disks. PowerPC targets. These concerns drove the decision to Furthermore, the root filesystem installed on the network use a custom Linux platform built from the ground-up. filesystem would creep away from its original state over ____________________________________________ * Operated by Fermi Research Alliance, LLC under Contract time without version control system in place. No. De-AC02-07CH11359 with the United States Department of Energy # [email protected] ISBN 978-3-95450-148-9 Copyright ©926 2015 CC-BY-3.0 and by the respective authors Software Technology Evolution Proceedings of ICALEPCS2015, Melbourne, Australia WEPGF096 CONTROL SYSTEM INTEGRATION interface remained the same and the bridge software was moved into the Erlang framework. An alternate method At first the support libraries available for integrating was developed that replaced the PEP protocol with RTAI with the Fermilab accelerator controls system (ACNET) message queues and shared memory. This method allows [6] [7] only supported VxWorks. Package Exchange large amounts of data to be shared between the ACNET Protocol (PEP), a light weight UDP protocol was process and the data acquisition process without developed to bridge communication between Linux transferring through a UDP socket. targets and VxWorks targets (Fig. 1). Support software that ran on a VxWorks target was deployed to bridge communication between ACNET and Linux targets deployed in the field. This method was successful and supported many, but not all of the features expected from an ACNET front end node. Figure 3. Replacing PEP with RTAI IPC methods. LOOKING TO IMPROVE Out of the experience of building a real-time embedded Linux platform from scratch came three desired improvements: Figure 1. Method for using PEP to bridge ACNET request 1. A smaller footprint operating system that could be to Linux Targets. packaged into a network-deliverable boot-image 2. An automated system for building kernel and root filesystem that could support multiple target Later, a suite of software was developed for interfacing architectures and hardware configurations Linux front end nodes with ACNET [8]. This ACNET 3. An integrated system for building and deploying support software is written in Erlang and runs inside of application software the Erlang virtual machine as its own process (Fig. 2). To address these improvements an effort was begun to Using this software the user can write data acquisition look to the open source community for a “best-practice” drivers in Erlang or using a C++ API. The challenge in approach to deploying an embedded Linux platform. this model is how to attach the data acquisition driver, running in its own process to the real-time application BUILDROOT running in another process. The decision was made to again utilize the PEP protocol to forward ACNET Buildroot is an open source build system with a menu- requests to the real-time application process. In this driven configuration tool (similar to the Linux kernel architecture the communication was done with local build system) that completely automates this process sockets instead of over Ethernet. (Fig. 4). It supports ucLibc [9], a low-footprint alternative to the GNU standard C library and Busybox [10], which combines many of the standard UNIX utilities and a shell into a single low-footprint executable. Figure 2. ACNET process utilizing PEP for inter-process communication. Using this architecture the existing applications using the bridge method were adapted to the new Linux ACNET platform without much effort (Fig. 3). The Figure 4. Buildroot configuration menu. ISBN 978-3-95450-148-9 Software Technology Evolution 927 Copyright © 2015 CC-BY-3.0 and by the respective authors WEPGF096 Proceedings of ICALEPCS2015, Melbourne, Australia In addition to providing a kernel, shell and basic GRUB must be built with the support for the network utilities, hundreds of software packages are supported. adapter on the target. The network configuration is stored The user simply selects which software package to in GRUB menu.lst file, which resides on the flash disk’s include in the boot-image and the build system boot partition. downloads, unpacks, configures, compiles and installs it. The Buildroot configuration system includes an option to APPLICATION BUILD ENVIRONMENT combine the kernel and root filesystem into a single All software that runs on the target must be built with bzImage at the end of the build process. A boot-loader the toolchain that Buildroot builds as the first step in the and this bzImage file are the only components needed to build process. A set of Makefiles was developed that boot an embedded Linux target. could be included in a developer’s C/C++ project that The first build usually takes a couple of hours, builds using this toolchain. Deploying to remote targets depending on the processing power and network is supported using scp and ssh or by mounting a remote bandwidth of the build machine.
Load more

Recommended publications
  • Nintendo Wii Software
    Nintendo wii software A previous update, ( U) introduced the ability to transfer your data from one Wii U console to another. You can transfer save data for Wii U software, Mii. The Wii U video game console's built-in software lets you watch movies and have fun right out of the box. BTW, why does it sound like you guys are crying about me installing homebrew software on my Wii console? I am just wondering because it seems a few of you. The Nintendo Wii was introduced in and, since then, over pay for any of this software, which is provided free of charge to everyone. Perform to Popular Chart-Topping Tunes - Sing up to 30 top hits from Season 1; Gleek Out to Never-Before-Seen Clips from the Show – Perform to video. a wiki dedicated to homebrew on the Nintendo Wii. We have 1, articles. Install the Homebrew Channel on your Wii console by following the homebrew setup tutorial. Browse the Homebrew, Wii hardware, Wii software, Development. The Wii was not designed by Nintendo to support homebrew. There is no guarantee that using homebrew software will not harm your Wii. A crazy software issue has come up. It's been around 10 months since the wii u was turned on at all. Now that we have, it boots up fine and you. Thus, we developed a balance assessment software using the Nintendo Wii Balance Board, investigated its reliability and validity, and. In Q1, Nintendo DS software sales were million, up million units Wii software sales reached million units, a million.
    [Show full text]
  • Embedded Linux Systems with the Yocto Project™
    OPEN SOURCE SOFTWARE DEVELOPMENT SERIES Embedded Linux Systems with the Yocto Project" FREE SAMPLE CHAPTER SHARE WITH OTHERS �f, � � � � Embedded Linux Systems with the Yocto ProjectTM This page intentionally left blank Embedded Linux Systems with the Yocto ProjectTM Rudolf J. Streif Boston • Columbus • Indianapolis • New York • San Francisco • Amsterdam • Cape Town Dubai • London • Madrid • Milan • Munich • Paris • Montreal • Toronto • Delhi • Mexico City São Paulo • Sidney • Hong Kong • Seoul • Singapore • Taipei • Tokyo Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. For information about buying this title in bulk quantities, or for special sales opportunities (which may include electronic versions; custom cover designs; and content particular to your business, training goals, marketing focus, or branding interests), please contact our corporate sales depart- ment at [email protected] or (800) 382-3419. For government sales inquiries, please contact [email protected]. For questions about sales outside the U.S., please contact [email protected]. Visit us on the Web: informit.com Cataloging-in-Publication Data is on file with the Library of Congress.
    [Show full text]
  • Design Languages for Embedded Systems
    Design Languages for Embedded Systems Stephen A. Edwards Columbia University, New York [email protected] May, 2003 Abstract ward hardware simulation. VHDL’s primitive are assign- ments such as a = b + c or procedural code. Verilog adds Embedded systems are application-specific computers that transistor and logic gate primitives, and allows new ones to interact with the physical world. Each has a diverse set be defined with truth tables. of tasks to perform, and although a very flexible language might be able to handle all of them, instead a variety of Both languages allow concurrent processes to be de- problem-domain-specific languages have evolved that are scribed procedurally. Such processes sleep until awak- easier to write, analyze, and compile. ened by an event that causes them to run, read and write variables, and suspend. Processes may wait for a pe- This paper surveys some of the more important lan- riod of time (e.g., #10 in Verilog, wait for 10ns in guages, introducing their central ideas quickly without go- VHDL), a value change (@(a or b), wait on a,b), ing into detail. A small example of each is included. or an event (@(posedge clk), wait on clk un- 1 Introduction til clk='1'). An embedded system is a computer masquerading as a non- VHDL communication is more disciplined and flexible. computer that must perform a small set of tasks cheaply and Verilog communicates through wires or regs: shared mem- efficiently. A typical system might have communication, ory locations that can cause race conditions. VHDL’s sig- signal processing, and user interface tasks to perform.
    [Show full text]
  • Sr. Firmware - Embedded Software Engineer
    SR. FIRMWARE - EMBEDDED SOFTWARE ENGINEER Atel USA is a leading provider of high-performance, small form-factor tracking systems for the vehicle recovery, fleet, heavy trucks, and asset tracking industries. Our team has years of experience in developing complex wireless and communications systems. We have shipped several millions of vehicle tracking devices operating on all major cellular networks. We are seeking an enthusiastic embedded software engineer to be a key team member in the design, implementation, and verification of our asset tracking devices and sensory accessories. The Sr. Firmware Engineer will become an integral part of our company and will work as part of a small, multi-disciplinary development team to design, construct and deliver software/firmware for our current and next generation products. Primary Responsibilities: • Work independently on project tasks as well as work as a team member of a larger project team. • Collaborate with hardware/system design engineers to define the product feature set and work within a product development team to deliver firmware that meets or exceeds product requirements. • Engage with customers and product managers to define requirements, develop software architecture, and plan development in dynamic, evolving customer driven environment. • Deliver innovative solutions from concept to prototype to production. • Conduct/participate in engineering reviews to provide technical input on product designs and quality. • Conduct software unit tests to exercise implemented functionality. • Document software designs. • Troubleshoot and remove defects from production software. • Communicate and interact with team and customers to clearly set expectations, share technical details, resolve issues, and report progress. • Participate in brainstorms and otherwise contribute outside your area of expertise.
    [Show full text]
  • Sr. Embedded Software/ Firmware Engineer This Position Is Located at the Corporate Headquarters in Henderson, Nevada
    Sr. Embedded Software/ Firmware Engineer This position is located at the Corporate Headquarters in Henderson, Nevada VadaTech, Inc. is seeking experienced candidates for Senior Embedded Software/Firmware Engineer. Primary Responsibilities: • Responsible for the focus on BIOS and board bring up • Responsible for the coordinating and prioritizing application modifications and bug fixes • Responsible for working with the customer support team to troubleshoot and resolve production issues • Responsible for the support, maintenance and documentation of software functionality • Responsible for Contributing to the development of internal tools to streamline the engineering and build and release processes • Responsible for the production of functional specifications and design documents Desired Skills and Experience • Bachelor’s degree in computer science or related field; master’s degree preferred • 8+ years of related work experience • Fluency in C programming required • Experience with Embedded Bootloader/OS porting required • Experience with U-Boot/Embedded Linux porting and PC BIOS maintenance preferred • Experience with new/untested hardware board bring-up required • Demonstrated ability to read hardware schematics and use lab instruments such as oscilloscopes, multimeters and JTAG probes to resolve problems required • Must be knowledgeable in low-level board-support software/hardware interfacing for DDR3 memory, local bus timings, Ethernet PHYs, NOR/NAND flash, I2C/SPI, and others • Experience with diverse CPU types such as PowerPC/PowerQUICC/QorIQ,
    [Show full text]
  • Embedded Linux Systems
    Dpto Sistemas Electrónicos y de Control Universidad Politécnica de Madrid Embedded Linux Systems Using Buildroot for building Embedded Linux Systems with the Raspberry-PI V1.2 Mariano Ruiz 2014 EUIT Telecomunicación Dpto. Sistemas Electrónicos y de C o n t r o l Page 1 of 41 Page 2 of 41 Table of contents 1 SCOPE ........................................................................................................................................ 6 1.1 Document Overview .............................................................................................................. 6 1.2 Acronyms .............................................................................................................................. 6 2 REFERENCED DOCUMENTS ......................................................................................................... 7 2.1 References ............................................................................................................................. 7 3 LAB1: BUILDING LINUX USING BUILDROOT ................................................................................. 8 3.1 Elements needed for the execution of these LABS. .................................................................. 8 3.2 Starting the VMware .............................................................................................................. 8 3.3 Configuring Buildroot. .......................................................................................................... 11 3.4 Compiling buildroot. ...........................................................................................................
    [Show full text]
  • 1.1 Purpose of Embedded System 1.2 Host and Target Machine 1.2.1
    e-PG Pathshala Subject : Computer Science Paper: Embedded System Module: Embedded Software Development Tools Module No: CS/ES/36 Quadrant 1 – e-text In this module, we will discuss about the host and target machine, Embedded Software development process and Embedded tools. 1.1 Purpose of Embedded System An embedded system is a special-purpose system in which the computer is completely encapsulated by the device it controls. Each embedded system has unique characteristics. The components and functions of hardware and software can be different for each system. Nowadays, embedded software is used in all the electronic devices such as watches, cellular phones etc. This embedded software is similar to general programming. But the embedded hardware is unique. The method of communication between interfaces can vary from processor to processor. It leads to more complexity of software. Engineers need to be aware of the software developing process and tools. There are a lot of things that software development tools can do automatically when the target platform is well defined. This automation is possible because the tools can exploit features of the hardware and operating system on which your program will execute. Embedded software development tools can rarely make assumptions about the target platform. Hence the user has to provide some explicit instructions of the system to the tools. Figure 1.1 shows how an embedded system is developed using a host and a target machine. 1.2 Host and Target machine Figure 1.1 Embedded system using host and target machine 1.2.1 Performance of Host machine The application program developed runs on the host computer.
    [Show full text]
  • Asurvey of Embedded Software Profiling Methodologies
    International Journal of Embedded Systems and Applications (IJESA) Vol.1, No.2, December 2011 A SURVEY OF EMBEDDED SOFTWARE PROFILING METHODOLOGIES Rajendra Patel1 and Arvind Rajawat 2 1,2 Department of Electronics and Communication Engineering, Maulana Azad National Institute of Technology, Bhopal, India 1 [email protected] [email protected] 2 ABSTRACT Embedded Systems combine one or more processor cores with dedicated logic running on an ASIC or FPGA to meet design goals at reasonable cost. It is achieved by profiling the application with variety of aspects like performance, memory usage, cache hit versus cache miss, energy consumption, etc. Out of these, performance estimation is more important than others. With ever increasing system complexities, it becomes quite necessary to carry out performance estimation of embedded software implemented in a particular processor for fast design space exploration. Such profiled data also guides the designer how to partition the system for Hardware (HW) and Software (SW) environments. In this paper, we propose a classification for currently available Embedded Software Profiling Tools, and we present different academic and industrial approaches in this context. Based on these observations, it will be easy to identify such common principles and needs which are required for a true Software Profiling Tool for a particular application. KEYWORDS Profiling, Embedded, Software, Performance, Methodology 1. INTRODUCTION In the design of embedded systems, design space exploration is performed to satisfy the application requirements. This can be achieved either by different architectural choices or by appropriate task partitioning. At the end the synthesis process generates the final solution with proper combination of Software, Hardware and Communication Structures.
    [Show full text]
  • Embedded Software Development Process and Tools: Lesson-1 Introduction to Embedded Software Development Process and Tools
    Embedded Software development Process and Tools: Lesson-1 Introduction to Embedded Software Development Process and Tools 2015 Chapter-14L01: "Embedded Software Development Process and 1 Tools, Publs.: McGraw-Hill Education 1. Development Process and Hardware─ Software 2015 Chapter-14L01: "Embedded Software Development Process and 2 Tools, Publs.: McGraw-Hill Education Cost of developing a final targeted system • Small processor cost • Larger time frame needed than the hardware circuit design • High development cost for final targeted system 2015 Chapter-14L01: "Embedded Software Development Process and 3 Tools, Publs.: McGraw-Hill Education Development Process • Edit-test-debug cycles • Fixed Processor and hardware parts once chosen • Application software codes perfected by a number of runs and tests. 2015 Chapter-14L01: "Embedded Software Development Process and 4 Tools, Publs.: McGraw-Hill Education Development process of an embedded system 2015 Chapter-14L01: "Embedded Software Development Process and 5 Tools, Publs.: McGraw-Hill Education Edit-Test-Debug Cycle implementation phase of the development process 2015 Chapter-14L01: "Embedded Software Development Process and 6 Tools, Publs.: McGraw-Hill Education 2. Software Tools 2015 Chapter-14L01: "Embedded Software Development Process and 7 Tools, Publs.: McGraw-Hill Education Software Tools • Software Development Lit (SDK) • Source-code Engineering Software • RTOS • Integrated Development Environment • Prototyper • Editor • Interpreter 2015 Chapter-14L01: "Embedded Software Development
    [Show full text]
  • Comparing Embedded Linux Build Systems and Distros
    Comparing embedded Linux build systems and distros Drew Moseley Solutions Architect Mender.io Session overview ● Review of embedded Linux development challenges. ● Define build system and criteria. ● Discuss a few popular options. ● Give me an opportunity to learn about some of the other tools. Goal: Help new embedded Linux developers get started About me Drew Moseley Mender.io ○ 10 years in Embedded Linux/Yocto development. ○ Over-the-air updater for Embedded Linux ○ Longer than that in general Embedded Software. ○ Open source (Apache License, v2) ○ Project Lead and Solutions Architect. ○ Dual A/B rootfs layout (client) [email protected] ○ Remote deployment management (server) https://twitter.com/drewmoseley https://www.linkedin.com/in/drewmoseley/ ○ Under active development https://twitter.com/mender_io Challenges for Embedded Linux Developers Hardware variety Storage Media Software may be maintained in forks Cross development Initial device provisioning Simple Makefiles don't cut it (anymore) Facts: ● These systems are huge ● Dependency Hell is a thing ● Builds take a long time ● Builds take a lot of resources ● Embedded applications require significant customization ● Developers need to modify from defaults Build System Defined _Is_ _Is Not_ ● Mechanism to specify and build ● An IDE ○ Define hardware/BSP ● A Distribution components ● A deployment and provisioning ○ Integrate user-space tool applications; including custom ● An out-of-the-box solution code ● Need reproducibility ● Must support multiple developers ● Allow for parallel
    [Show full text]
  • Programming Embedded Systems, Second Edition with C and GNU Development Tools
    Programming Embedded Systems Second Edition Programming Embedded Systems, Second Edition with C and GNU Development Tools Foreword If you mention the word embedded to most people, they'll assume you're talking about reporters in a war zone. Few dictionaries—including the canonical Oxford English Dictionary—link embedded to computer systems. Yet embedded systems underlie nearly all of the electronic devices used today, from cell phones to garage door openers to medical instruments. By now, it's nearly impossible to build anything electronic without adding at least a small microprocessor and associated software. Vendors produce some nine billion microprocessors every year. Perhaps 100 or 150 million of those go into PCs. That's only about one percent of the units shipped. The other 99 percent go into embedded systems; clearly, this stealth business represents the very fabric of our highly technological society. And use of these technologies will only increase. Solutions to looming environmental problems will surely rest on the smarter use of resources enabled by embedded systems. One only has to look at the network of 32-bit processors in Toyota's hybrid Prius to get a glimpse of the future. Page 1 Programming Embedded Systems Second Edition Though prognostications are difficult, it is absolutely clear that consumers will continue to demand ever- brainier products requiring more microprocessors and huge increases in the corresponding software. Estimates suggest that the firmware content of most products doubles every 10 to 24 months. While the demand for more code is increasing, our productivity rates creep up only slowly. So it's also clear that the industry will need more embedded systems people in order to meet the demand.
    [Show full text]
  • Embedded Software Education: an RTOS-Based Approach
    Embedded Software Education: An RTOS-based Approach James Archibald Doran Wilde Electrical and Computer Engineering Dept. Electrical and Computer Engineering Dept. Brigham Young University Brigham Young University [email protected] [email protected] ABSTRACT Under the best of circumstances, the creation of functional Embedded computer systems are proliferating, but the com- software for non-trivial applications is demanding. Virtu- plexities of embedded software make it increasingly difficult ally no substantive software programs have been found to be to produce systems that are robust and reliable. These chal- error-free when subjected to careful analysis [1]. Embedded lenges increase as embedded systems are connected to net- developers face all the challenges of conventional software works and relied on to control or monitor physical processes and more. For example, embedded software typically must in critical infrastructure. This paper describes a senior-level interact directly with hardware, it must respond to time- course that exposes students to foundational characteristics critical events in specified time windows, and it often relies of embedded software, such as concurrency, synchronization on concurrency (processes, threads, interrupts) to meet re- and communication. The core of the class is a sequence of sponse time requirements. laboratory assignments in which students design and imple- ment a real-time operating system. Each student-developed Given the formidable task facing firmware developers, it is RTOS has the same API, so all can run the same applica- not surprising that the creation of embedded software is tion code, but internal implementations vary widely. The quantifiably more demanding than conventional software [8], principal challenges that arise in the design and debugging nor is it surprising that the same kinds of mistakes turn of a multi-tasking RTOS tend to be instances of the general up repeatedly during design and development [24].
    [Show full text]