DOCSLIB.ORG

Getting Started with Buildroot

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Getting Started with Buildroot Embedded Apprentice Linux Engineer Getting started with Buildroot Thomas Petazzoni [email protected] ľ Copyright 2004-2018, Bootlin. Creative Commons BY-SA 3.0 license. Formerly Free Electrons Corrections, suggestions, contributions and translations are welcome! - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 1/1 Thomas Petazzoni I Embedded Linux engineer at Free Electrons → Bootlin I Embedded Linux expertise I Development, consulting and training I Strong open-source focus I Freely available training materials I Open-source contributor I Living in Toulouse, France - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 2/1 Building an embedded Linux system + Readily available - Large, usually 100+ MB - Not available for all architectures - Not easy to customize - Generally require native compilation - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 3/1 Building an embedded Linux system + Smaller and flexible - Very hard to handle cross-compilation and dependencies - Not reproducible - No benefit from other people’s work - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 3/1 Building an embedded Linux system + Small and flexible + Reproducible, handles cross-compilation and dependencies + Available for virtually all architectures - One tool to learn - Build time - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 3/1 I Cross-compilation → leveraging fast build machines I Recipes for building components → easy Embedded Linux build system: principle I Building from source → lot of flexibility - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 4/1 I Recipes for building components → easy Embedded Linux build system: principle I Building from source → lot of flexibility I Cross-compilation → leveraging fast build machines - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 4/1 Embedded Linux build system: principle I Building from source → lot of flexibility I Cross-compilation → leveraging fast build machines I Recipes for building components → easy - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 4/1 Buildroot at a glance I Is an embedded Linux build system, builds from source: I cross-compilation toolchain I root filesystem with many libraries/applications, cross-built I kernel and bootloader images I Fast, simple root filesystem in minutes I Easy to use and understand: kconfig and make I Small root filesystem, default 2 MB I More than 2300 packages available I Generates filesystem images, not a distribution I Vendor neutral I Active community, stable releases every 3 months I Started in 2001, oldest still maintained build system I http://buildroot.org - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 5/1 Getting started $ git clone git://git.busybox.net/buildroot $ cd buildroot $ make menuconfig - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 6/1 2. Build options 3. Toolchain 4. System configuration 5. Kernel 6. Target packages 7. Filesystem images 8. Bootloaders 9. Host utilities Buildroot configuration 1. Target architecture I Architecture ARC, ARM, AArch64, Blackfin, csky, m68k, Microblaze, MIPS(64), NIOS II, OpenRisc, PowerPC(64), SuperH, SPARC, x86, x86 64, Xtensa I Specific processor I ABI I Floating point strategy - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 7/1 3. Toolchain 4. System configuration 5. Kernel 6. Target packages 7. Filesystem images 8. Bootloaders 9. Host utilities Buildroot configuration 1. Target architecture 2. Build options I Download directory I Number of parallel jobs I Use of ccache I Shared or static libraries I etc. - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 7/1 4. System configuration 5. Kernel 6. Target packages 7. Filesystem images 8. Bootloaders 9. Host utilities Buildroot configuration 1. Target architecture 2. Build options I Buildroot toolchain 3. Toolchain I Buildroot builds the toolchain I uClibc, glibc, musl I External toolchain I Uses a pre-built toolchain I Profiles for existing popular toolchains Linaro, Sourcery CodeBench, etc. I Custom toolchains - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 7/1 5. Kernel 6. Target packages 7. Filesystem images 8. Bootloaders 9. Host utilities Buildroot configuration 1. Target architecture 2. Build options I Init system to use: BusyBox, Sysvinit, Systemd 3. Toolchain I /dev management solution: static, devtmpfs, 4. System configuration mdev, udev I Hostname, password, getty terminal, etc. I Root filesystem overlay I Custom post build and post image scripts I etc. - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 7/1 6. Target packages 7. Filesystem images 8. Bootloaders 9. Host utilities Buildroot configuration 1. Target architecture 2. Build options 3. Toolchain I Kernel source (stable version, Git tree, patches) 4. System configuration I Kernel configuration 5. Kernel I Support for kernel extensions: RTAI, Xenomai, aufs, etc. - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 7/1 7. Filesystem images 8. Bootloaders 9. Host utilities Buildroot configuration 1. Target architecture I More than 2300 packages 2. Build options I Qt4, Qt5, X.org, Gtk, EFL 3. Toolchain I GStreamer, ffmpeg 4. System configuration I Python, Perl, Ruby, Lua, Erlang 5. Kernel I Samba, OpenSSL, OpenSSH, dropbear, 6. Target packages lighttpd I OpenGL support for various platforms I And many, many more libraries and utilities - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 7/1 8. Bootloaders 9. Host utilities Buildroot configuration I Major filesystem formats supported 1. Target architecture I cloop 2. Build options I cpio, for kernel initramfs 3. Toolchain I cramfs 4. System configuration I ext2/3/4 5. Kernel I jffs2 6. Target packages I romfs 7. Filesystem images I squashfs I tar I ubifs - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 7/1 9. Host utilities Buildroot configuration 1. Target architecture 2. Build options I Grub2 3. Toolchain I Syslinux 4. System configuration I U-Boot 5. Kernel I Barebox 6. Target packages I and more platform-specific bootloaders: 7. Filesystem images imx-bootlets, at91bootstrap, etc. 8. Bootloaders - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 7/1 Buildroot configuration 1. Target architecture 2. Build options 3. Toolchain 4. System configuration I Allows to build some native tools, useful for 5. Kernel development. 6. Target packages 7. Filesystem images 8. Bootloaders 9. Host utilities - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 7/1 Building and using I To start the build: make I Results in output/images: I rootfs.ext4, root filesystem in ext4 format I zImage, Linux kernel image I am335x-pocketbeagle.dtb, Linux kernel Device Tree blob I u-boot.img, U-Boot bootloader image I MLO, U-Boot bootloader image I Ready to be flashed on your embedded system. - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 8/1 Exploring the build output I All the output produced by Buildroot is stored in output/ I Can be customized using O= for out-of-tree build I output/ contains I output/build, with one sub-directory for the source code of each component I output/host, which contains all native utilities needed for the build, including the cross-compiler I output/host/<tuple>/sysroot, which contains all the headers and libraries built for the target I output/target, which contains almost the target root filesystem I output/images, the final images - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 9/1 Summarized build process 1. Check core dependencies 2. For each selected package, after taking care of its dependencies: download, extract, patch, configure, build, install I To target/ for target apps and libs I To host/<tuple>/sysroot for target libs I To host/ for native apps and libs I Filesystem skeleton and toolchain are handled as regular packages 3. Copy rootfs overlay 4. Call post build scripts 5. Generate the root filesystem image 6. Call post image scripts - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 10/1 Customizing the build Besides the existing packages and options, there are multiple ways to customize the generated root filesystem: I Create custom post-build and/or post-image scripts I Use a root filesystem overlay, recommended to add all your config files I Add your own packages - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 11/1 Adding a new package: Config.in package/libmicrohttpd/Config.in config BR2_PACKAGE_LIBMICROHTTPD bool "libmicrohttpd" depends on BR2_TOOLCHAIN_HAS_THREADS
Load more

Recommended publications
  • Shorten Device Boot Time for Automotive IVI and Navigation Systems
    Shorten Device Boot Time for Automotive IVI and Navigation Systems Jim Huang ( 黃敬群 ) <[email protected]> Dr. Shi-wu Lo <[email protected]> May 28, 2013 / Automotive Linux Summit (Spring) Rights to copy © Copyright 2013 0xlab http://0xlab.org/ [email protected] Attribution – ShareAlike 3.0 Corrections, suggestions, contributions and translations You are free are welcome! to copy, distribute, display, and perform the work to make derivative works Latest update: May 28, 2013 to make commercial use of the work Under the following conditions Attribution. You must give the original author credit. Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one. For any reuse or distribution, you must make clear to others the license terms of this work. Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above. License text: http://creativecommons.org/licenses/by-sa/3.0/legalcode Goal of This Presentation • Propose a practical approach of the mixture of ARM hibernation (suspend to disk) and Linux user-space checkpointing – to shorten device boot time • An intrusive technique for Android/Linux – minimal init script and root file system changes are required • Boot time is one of the key factors for Automotive IVI – mentioned by “Linux Powered Clusters” and “Silver Bullet of Virtualization (Pitfalls, Challenges and Concerns) Continued” at ALS 2013 – highlighted by “Boot Time Optimizations” at ALS 2012 About this presentation • joint development efforts of the following entities – 0xlab team - http://0xlab.org/ – OSLab, National Chung Cheng University of Taiwan, led by Dr.
    [Show full text]
  • Connecting Peripheral Devices to a Pandaboard Using
    11/16/2012 MARK CONNECTING PERIPHERAL DEVICES TO A BIRDSALL PANDABOARD USING PSI This is an application note that will help somebody use the Serial Programming Interface that is available on the OMAP-based PandaBoard’s expansion connector and also explains how use the SPI to connect with a real-time clock (RTC) chip. Ever since the PandaBoard came out, there has been a community of eager programmers constructing creative projects and asking questions about where else and what more they could do to extend the PandaBoard’s abilities. This application note will document a way to connect devices to a OMAP-based devise like a PandaBoard What is the Serial Programming Interface “Serial Programming Interface” (SPI) is a simple standard that was developed my Motorola. SPI can also be called “4-wire” interface (as opposed to 1, 2 or 3-wire serial buses) and it is sometimes referred to like that because the interface has four wires defined. The first is Master- Out-Slave-In (MOSI) and the second is the Master-In-Slave-Out (MISO). There is also a Serial Clock from the Master (SCLK) and a Chipselect Signal (CS#) which can allow for more than one slave devise to be able to connect with one master. Why do we want to use the SPI? There are various ways to connect a peripheral device to the PandaBoard like USB, SPI, etc... and SPI has some advantages. Using the Serial Programming Interface costs less in terms of power usage and it is easy to connect different devises to the PandaBoard and also to debug any problems that occur all while maintaining an acceptable performance rate.
    [Show full text]
  • Deliverable D4.1
    Deliverable D4.1 – State of the art on performance and power estimation of embedded and high-performance cores Anastasiia Butko, Abdoulaye Gamatié, Gilles Sassatelli, Stefano Bernabovi, Michael Chapman, Philippe Naudin To cite this version: Anastasiia Butko, Abdoulaye Gamatié, Gilles Sassatelli, Stefano Bernabovi, Michael Chapman, et al.. Deliverable D4.1 – State of the art on performance and power estimation of embedded and high- performance cores. [Research Report] LIRMM (UM, CNRS); Cortus S.A.S. 2016. lirmm-03168326 HAL Id: lirmm-03168326 https://hal-lirmm.ccsd.cnrs.fr/lirmm-03168326 Submitted on 12 Mar 2021 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Project Ref. Number ANR-15-CE25-0007 D4.1 – State of the art on performance and power estimation of embedded and high-performance cores Version 2.0 (2016) Final Public Distribution Main contributors: A. Butko, A. Gamatié, G. Sassatelli (LIRMM); S. Bernabovi, M. Chapman and P. Naudin (Cortus) Project Partners: Cortus S.A.S, Inria, LIRMM Every effort has been made to ensure that all statements and information contained herein are accurate, however the Continuum Project Partners accept no liability for any error or omission in the same.
    [Show full text]
  • Cubietruck – Mini PC
    SPRZĘT Cubietruck – mini PC Rynek komputerków jednopłytkowych opartych o procesory ARM zapoczątkowany przez Raspberry Pi rozwija się doskonale. Może nie jak grzyby po deszczu, ale systematycznie pojawiają się nowe rozwiązania: BeagleBoard, Marsboard, Cubieboard, Olinuxino itp. Różnią się one wyposażeniem, wydajnością, dostępnością dokumentacji oraz wsparciem technicznym. Ciekawie rozwija się propozycja Cubieboard. mocujących. Niby nic, ale te trzy kawałki two- org, zapoczątkowana płytką Cubieboard A10 rzywa i paczka tulejek umożliwiają poskładanie Fotografi a 3. Obudowa Cubietruck (opisaną w EP06/2013) i Cubieboard2 zgod- samodzielnego systemu mini-PC wyposażo- ną mechanicznie, ale zbudowaną w oparciu nego w dysk HDD 2,5”, wystarczająco zabez- rolę domowego centrum multimedialnego lub o nowszy, dwurdzeniowy procesor A20, zwięk- pieczając mechanicznie jego elementy. Osłony Linuxowego komputera PC. Jedyne zastrzeżenie szający wydajność Cubie i paletę jej zastosowań w odpowiednich miejscach mają wyfrezowane można mieć do kilku różnokolorowych LED, (fotografi a 1). Najnowsza propozycja to Cubie- otwory umożliwiające korzystanie z GPIO bez bezlitośnie informujących nasze oczy o stanie truck (Cubieboard3), oparty podobnie jak Cu- zdejmowania obudowy. pracy Cubie. bieboard2 (fotografi a 2) o procesor Allwinner Ciekawą propozycją dla osób wykorzy- Cubieboard3 oparty jest o SoC w architektu- A20, lecz mający znacznie bogatsze wyposaże- stujących Cubieboard3 w roli samodzielnego rze ARM7 – Allwinner A20, który w połączeniu nie, co niestety wiąże się z wyższą ceną. Porów- mini-PC, jest pełna obudowa pokazana na fo- ze sporej wielkości dyskiem NAND Flash oraz nanie parametrów poszczególnych komputer- tografi i 3. W swoim wnętrzu mieści swobodnie zwiększoną pamięcią RAM bezproblemowo ków Cubieboard umieszczono w tabeli 1. płytkę Cubieboard3, dysk HDD 2,5” (fotogra- sprawdza się w roli komputera PC pracującego Podobnie jak w przypadku poprzednich fi a 4) i przewody połączeniowe.
    [Show full text]
  • The Linux Kernel Module Programming Guide
    The Linux Kernel Module Programming Guide Peter Jay Salzman Michael Burian Ori Pomerantz Copyright © 2001 Peter Jay Salzman 2007−05−18 ver 2.6.4 The Linux Kernel Module Programming Guide is a free book; you may reproduce and/or modify it under the terms of the Open Software License, version 1.1. You can obtain a copy of this license at http://opensource.org/licenses/osl.php. This book is distributed in the hope it will be useful, but without any warranty, without even the implied warranty of merchantability or fitness for a particular purpose. The author encourages wide distribution of this book for personal or commercial use, provided the above copyright notice remains intact and the method adheres to the provisions of the Open Software License. In summary, you may copy and distribute this book free of charge or for a profit. No explicit permission is required from the author for reproduction of this book in any medium, physical or electronic. Derivative works and translations of this document must be placed under the Open Software License, and the original copyright notice must remain intact. If you have contributed new material to this book, you must make the material and source code available for your revisions. Please make revisions and updates available directly to the document maintainer, Peter Jay Salzman <[email protected]>. This will allow for the merging of updates and provide consistent revisions to the Linux community. If you publish or distribute this book commercially, donations, royalties, and/or printed copies are greatly appreciated by the author and the Linux Documentation Project (LDP).
    [Show full text]
  • Create an Email with Subject Title “Embedded Software Engineer”, Email a Copy of Your Resume to [email protected]
    To Apply for This Position: Create an email with subject title “Embedded Software Engineer”, email a copy of your resume to [email protected] Location Address: ALLEN PARK, MI,48101 Position Description: TITLE: Embedded Software Engineer ‐ Hypervisor OS technologies This position is responsible to develop QNX and Android operating system images for Ford infotainment products. This includes creating and integrating code for: bootloader, kernel, drivers, type 1 hypervisor, and build environment. Skills Required: • Lead the design, bring‐up and support of QNX and Android operating system images • Create virt‐io drivers for QNX or Android guest operating systems • Participate in root cause analysis of hardware quality problems and software defects • Participate in system design, documentation, and testing to deliver a best‐in‐class infotainment system Experience Required: • 5+ years operating system experience involving Linux or QNX • 5+ years C/C++ software development experience on embedded, mobile, or consumer electronic platforms Experience Preferred: • Experience with Type 1 hypervisors • Experience creating virt‐io drivers • Mastery of C/C++ language, GNU tool chain, and Unix (QNX, Linux, or equivalent) • Experience with embedded build systems including QNX system builder, buildroot, yocto, or equivalent • Knowledge of in‐vehicle signaling and communication mechanisms such as CAN • Proficiency with revision control including Git, Subversion, or equivalent • Multi‐site software project team experience Education Required: • Bachelor's degree in Computer Engineering, Electrical Engineering, Computer Science, or related Education Preferred: • Master's degree in Computer Engineering, Electrical Engineering or Computer Science Additional Information: Web Based Assessment not required for this position. Visa Sponsorship and Domestic Relocation is available for this position.
    [Show full text]
  • Industrial Control Via Application Containers: Migrating from Bare-Metal to IAAS
    Industrial Control via Application Containers: Migrating from Bare-Metal to IAAS Florian Hofer, Student Member, IEEE Martin A. Sehr Antonio Iannopollo, Member, IEEE Faculty of Computer Science Corporate Technology EECS Department Free University of Bolzano-Bozen Siemens Corporation University of California Bolzano, Italy Berkeley, CA 94704, USA Berkeley, CA 94720, USA fl[email protected] [email protected] [email protected] Ines Ugalde Alberto Sangiovanni-Vincentelli, Fellow, IEEE Barbara Russo Corporate Technology EECS Department Faculty of Computer Science Siemens Corporation University of California Free University of Bolzano-Bozen Berkeley, CA 94704, USA Berkeley, CA 94720, USA Bolzano, Italy [email protected] [email protected] [email protected] Abstract—We explore the challenges and opportunities of control design full authority over the environment in which shifting industrial control software from dedicated hardware to its software will run, it is not straightforward to determine bare-metal servers or cloud computing platforms using off the under what conditions the software can be executed on cloud shelf technologies. In particular, we demonstrate that executing time-critical applications on cloud platforms is viable based on computing platforms due to resource virtualization. Yet, we a series of dedicated latency tests targeting relevant real-time believe that the principles of Industry 4.0 present a unique configurations. opportunity to explore complementing traditional automation Index Terms—Industrial Control Systems, Real-Time, IAAS, components with a novel control architecture [3]. Containers, Determinism We believe that modern virtualization techniques such as application containerization [3]–[5] are essential for adequate I. INTRODUCTION utilization of cloud computing resources in industrial con- Emerging technologies such as the Internet of Things and trol systems.
    [Show full text]
  • CNTR: Lightweight OS Containers
    CNTR: Lightweight OS Containers Jorg¨ Thalheim, Pramod Bhatotia Pedro Fonseca Baris Kasikci University of Edinburgh University of Washington University of Michigan Abstract fundamental to achieve high efficiency in virtualized datacenters and enables important use-cases, namely Container-based virtualization has become the de-facto just-in-time deployment of applications. Moreover, standard for deploying applications in data centers. containers significantly reduce operational costs through However, deployed containers frequently include a higher consolidation density and power minimization, wide-range of tools (e.g., debuggers) that are not required especially in multi-tenant environments. Because of all for applications in the common use-case, but they these advantages, it is no surprise that containers have seen are included for rare occasions such as in-production wide-spread adoption by industry, in many cases replacing debugging. As a consequence, containers are significantly altogether traditional virtualization solutions [17]. larger than necessary for the common case, thus increasing the build and deployment time. Despite being lightweight, deployed containers often include a wide-range of tools such as shells, editors, CNTR1 provides the performance benefits of lightweight coreutils, and package managers. These additional tools containers and the functionality of large containers by are usually not required for the application’s core function splitting the traditional container image into two parts: the — the common operational use-case — but they are “fat” image — containing the tools, and the “slim” image included for management, manual inspection, profiling, — containing the main application. At run-time, CNTR and debugging purposes [64]. In practice, this significantly allows the user to efficiently deploy the “slim” image and increases container size and, in turn, translates into then expand it with additional tools, when and if necessary, slower container deployment and inefficient datacenter by dynamically attaching the “fat” image.
    [Show full text]
  • Version 7.8-Systemd
    Linux From Scratch Version 7.8-systemd Created by Gerard Beekmans Edited by Douglas R. Reno Linux From Scratch: Version 7.8-systemd by Created by Gerard Beekmans and Edited by Douglas R. Reno Copyright © 1999-2015 Gerard Beekmans Copyright © 1999-2015, Gerard Beekmans All rights reserved. This book is licensed under a Creative Commons License. Computer instructions may be extracted from the book under the MIT License. Linux® is a registered trademark of Linus Torvalds. Linux From Scratch - Version 7.8-systemd Table of Contents Preface .......................................................................................................................................................................... vii i. Foreword ............................................................................................................................................................. vii ii. Audience ............................................................................................................................................................ vii iii. LFS Target Architectures ................................................................................................................................ viii iv. LFS and Standards ............................................................................................................................................ ix v. Rationale for Packages in the Book .................................................................................................................... x vi. Prerequisites
    [Show full text]
  • RTAI-Lab Tutorial: Scicoslab, Comedi, and Real-Time Control
    RTAI-Lab tutorial: Scicoslab, Comedi, and real-time control Roberto Bucher 1 Simone Mannori Thomas Netter 2 May 24, 2010 Summary RTAI-Lab is a tool chain for real-time software and control system development. This tutorial shows how to install the various components: the RTAI real-time Linux kernel, the Comedi interface for control and measurement hardware, the Scicoslab GUI-based CACSD modeling software and associated RTAI-Lab blocks, and the xrtailab interactive oscilloscope. RTAI-Lab’s Scicos blocks are detailed and examples show how to develop elementary block diagrams, automatically generate real-time executables, and add custom elements. 1Main RTAI-Lab developer, person to contact for technical questions: roberto.bucher at supsi.ch, see page 46 Contents 1 Introduction 4 1.1 RTAI-Lab tool chain . .4 1.2 Commercial software . .4 2 Installation 5 2.1 Requirements . .5 2.1.1 Hardware requirements . .5 2.1.2 Software requirements . .6 2.2 Mesa library . .7 2.3 EFLTK library . .7 2.4 Linux kernel and RTAI patch . .7 2.5 Comedilib . .8 2.6 RTAI (1st pass) . .8 2.7 RTAI tests . .9 2.8 Comedi . .9 2.9 RTAI (2nd pass) . 10 2.10 ScicosLab . 11 2.11 RTAI-Lab add-ons to Scicoslab-4.4 . 11 2.12 User configuration for scicoslab-4.4 . 11 2.13 Load the modules . 11 3 Development with RTAI-Lab 13 3.1 Boot Linux-RTAI . 13 3.2 Start Scicos . 13 3.3 RTAI-Lib palette . 14 3.4 Real-time sinewave: step by step . 16 3.4.1 Create block diagram .
    [Show full text]
  • Improving the Beaglebone Board with Embedded Ubuntu, Enhanced GPMC Driver and Python for Communication and Graphical Prototypes
    Final Master Thesis Improving the BeagleBone board with embedded Ubuntu, enhanced GPMC driver and Python for communication and graphical prototypes By RUBÉN GONZÁLEZ MUÑOZ Directed by MANUEL M. DOMINGUEZ PUMAR FINAL MASTER THESIS 30 ECTS, JULY 2015, ELECTRICAL AND ELECTRONICS ENGINEERING Abstract Abstract BeagleBone is a low price, small size Linux embedded microcomputer with a full set of I/O pins and processing power for real-time applications, also expandable with cape pluggable boards. The current work has been focused on improving the performance of this board. In this case, the BeagleBone comes with a pre-installed Angstrom OS and with a cape board using a particular software “overlay” and applications. Due to a lack of support, this pre-installed OS has been replaced by Ubuntu. As a consequence, the cape software and applications need to be adapted. Another necessity that emerges from the stated changes is to improve the communications through a GPMC interface. The depicted driver has been built for the new system as well as synchronous variants, also developed and tested. Finally, a set of applications in Python using the cape functionalities has been developed. Some extra graphical features have been included as example. Contents Contents Abstract ..................................................................................................................................................................................... 5 List of figures .........................................................................................................................................................................
    [Show full text]
  • OS Selection for Dummies
    OS SELECTION HOW TO CHOOSE HOW TO CHOOSE Choosing your OS is the first step, so take the time to consider your choice fully. There are many parameters to take into account: l Is this a new project or the evolution of an existing product? l Using the same SW stack? Re-using existing code? l Is your team familiar with a particular OS? Ø Using an OS you are already comfortable with can help l What are the HW constraints of your system? Ø Some operating systems require more memory/processing power than others l Have no SW team? Not sure about the above? Ø Contact us so we can help you decide! Ø We can also introduce you to one of our many partners! 1 OS SELECTION OPEN SOURCE VS. COMMERCIAL OS Embedded OS BSP Provider $ Cost Open-Source OS Boundary Devices • Embedded Linux / Android Embedded Linux $0, included • Large pool of developers available with Board Purchase • Strong community • Royalty-free And / or partners 3rd Party - Commercial OS Partners • QNX / Win10 IoT / Green Hills $>0, depends on • Professional support requirements • Unique set of development tools 2 OS SELECTION OPEN SOURCE SELECTION OS SELECTION PROS CONS Embedded Linux Most powerful / optimized Complexity for newcomers solution, maintained by NXP • Build systems Ø Yocto / Buildroot Simpler solution, makefile- Not as flexible as Yocto Ø Everything built from scratch based, maintained by BD Desktop-like approach, Harder to customize, non- Package-based distribution easy-to-use atomic updates, no cross- • Ubuntu / Debian compilation SDK Apt install / update, millions • Packages installed from server of prebuilt packages available Android Millions of apps available, same number of developers, Resource-hungry, complex • AOSP-based (no GMS) development environment, BSP modifications (HAL) • APK applications IDE + debugging tools 3 SOFTWARE PARTNERS Boundary Devices has an industry-leading group of software partners.
    [Show full text]