Importing Open-BTS Software on BeagleBoard

By

Ahmed Fouad Ahmed Marzban Ahmed Sayed Mohamed Ali Ayman Nedaa Elkadi Mahmoud Omar Desouky Ali Mohamed Abd-Elkhalek Mohamed Osman

Under the supervision of Prof.Dr. Magdi Fikri

A Graduation Project Report Submitted to the Faculty of Engineering at Cairo University in Partial Fulfillment of the Requirements for the Degree of Bachelor of Science in Electronics and Communications Engineering Faculty of Engineering, Cairo University Giza, Egypt July 2011

Importing Open-BTS Software on BeagleBoard

2011

Table of Contents
List of Tables ..............................................................................................................vii List of Figures ........................................................................................................... viii List of Symbols and Abbreviations .............................................................................. ix Acknowledgments ........................................................................................................ xi Abstract .......................................................................................................................xii Chapter 1: 1.1 1.2 1.3 1.4 Introduction ............................................................................................. 1 1 1 2 4

Software Defined Radio The Basic Architecture of SDR system Open-BTS Current Work in the Open-BTS project

Chapter 2:

GNU Radio ............................................................................................. 5 5 6 6 6 7 8

2.1 GNU Radio 2.1.1 2.2 How to write signal processing blocks in GNU Radio

Python 2.2.1 2.2.2 2.2.3 Python programming language Overview Python VS GNU Radio What does Python do to import a module?

Chapter 3:

BeagleBoard-xM ................................................................................... 10 10 10 11 11

3.1 What is BeagleBoard? 3.2 BeagleBoard Versions 3.3 BeagleBoard Specifications 3.3.1 BeagleBoard Features

i

Importing Open-BTS Software on BeagleBoard
3.3.2 3.3.3 3.3.4 Chapter 4: Processor Memory Power Management 12 13 13

2011

Tools needed to start working on BeagleBoard ………………………14 14 15 16 16 17 19

4.1 OpenEmbedded 4.1.1 4.1.2 4.2 Installation of OE Building Distributions with OpenEmbedded

BitBake 4.2.1 4.2.2 Usage of BitBake Writing your own receipe

Chapter 5:

GPP/DSP communication tools ……………………………………...20 20 20 22 23 24 24 25 25 26 27 On the GPP side On the DSP side 28 28 29 29

5.1 DSP/BIOS 5.1.1 5.1.2 5.1.3 DSP/BIOS Features DSP/BIOS API DSP/BIOS Configuration 5.1.3.1 Files Used to create DSP/BIOS programs 5.1.3.1.1 5.1.3.1.2 5.1.3.1.3 5.2 DSP/BIOS LINK 5.2.1 Overview 5.2.1.1 5.2.1.2 Program Files Files Used to create DSP/BIOS Programs Static Configurations

5.2.2 Key Components 5.2.2.1 PROC

ii

Importing Open-BTS Software on BeagleBoard
5.2.2.1.1 5.2.2.1.2 5.2.2.1.3 5.2.2.2 POOL 5.2.2.2.1 5.2.2.2.2 5.2.2.2.3 5.2.2.3 CHNL 5.2.2.3.1 5.2.2.3.2 5.2.2.3.3 INITIALIZATION EXECUTION FINILIZATION INITIALIZATION EXECUTION FINILIZATION INITIALIZATION EXECUTION FINILIZATION 29 30 30 31 31 32 32 32 33 33 34 34 34 35 35 35 36 37 37

2011

5.2.3 Getting started with applications 5.2.3.1 5.2.3.2 Generic Information Component Features 5.2.3.2.1 5.2.3.2.2 5.2.3.2.3 5.2.3.2.4 5.2.3.2.5 5.2.3.3 NOTIFY MSGQ MPLIST CHNL RingIO

Static buffer system with minimal controlcommunication with the DSP 5.2.3.3.1 5.2.3.3.2 Application requirements DSP/BIOS LINK components used 38 38 39

5.2.3.4

Dynamic buffer system with minimal controlcommunication with the DSP 40

iii

Importing Open-BTS Software on BeagleBoard
5.2.3.4.1 5.2.3.4.2 5.2.3.5 Application requirements DSP/BIOS LINK components used 40 41

2011

Multiple buffer to be sent betweeen GPP and DSP 41 5.2.3.5.1 5.2.3.5.2 Application requirements DSP/BIOS LINK components used 41 43 43 43 44 44 45 45 46 47 47 47 49 What is C6EZRUN? What Does C6EZRUN Actually do? What Does C6EZRUN Consists Of? 5.3.1.3.1 C6RUNLIB 49 50 50 50

5.2.4

Support for multiple DSP boot modes 5.2.4.1 Normal Boot Mode 5.2.4.1.1 5.2.4.1.2 5.2.4.2 DSP_BootMode_Boot_NoPwr DSP_BootMode_Boot_Pwr

External Load Mode 5.2.4.1.1 DSP_BootMode_Boot_Noload_NoPwr

5.2.4.3

External Load and Start Mode 5.2.4.3.1 DSP_BootMode_NoBoot

5.2.5

Installation of DSPLINK

5.3 Other GPP/DSP Communication Tools 5.3.1 C6EZRUN 5.3.1.1 5.3.1.2 5.3.1.3

5.3.1.3.1.1 5.3.1.3.2

C6RUNLIB Front-End Tool Usage 51 53

C6RUNAPP

5.3.1.3.2.1 5.3.1.4

C6RUNAPP Front-End Tool Usage 53 54 54

How To Compile an Example 5.3.1.4.1 Incase Of Using C6RUNLIB

iv

Importing Open-BTS Software on BeagleBoard
5.3.1.4.2 5.3.1.5 Chapter 6: Incase Of Using C6RUNAPP 55 57

2011

Installation Of C6EZRUN

Executing GNURadio Blocks on DSP ………………………………..58 58 59 62 63 65 65 65 65 65 66 66 66 66 67 67 67 68

6.1 Components to Set Up GPP/DSP SDR Based Applications 6.1.1 6.1.2 GPP Side Library DSP-Side Executable

6.1.3 GNURadio DSP-Based Blocks 6.2 Compilation and Execution of LoopAl2 Sample 6.2.1 6.2.2 Assumptions What's Included 6.2.2.1 DSPLINK-Code 6.2.2.1.1 6.2.2.1.2 6.2.2.2 6.2.2.3 6.2.2.4 6.2.2.5 6.2.2.6 6.2.3 6.2.4 DSP GPP

Sample_make files InitBeagle.sh OE-Receipes Omap_sample_flowgraphs Pre_backed_packages-2 6 37

Building OE Recipes List of Blocks

Analysis ……………………………………………………………...…………...……70 Conclusion …………………………………………………………..…………... ……71
.

Recommendation for future work ……………………………………………………..72 References ……………………………………………………………………………..73 Appendix-A ……………………………………………………………………………74

v

Importing Open-BTS Software on BeagleBoard
A.1 A.2 A.3 Environment Variables for OE The Configuration file for OE (local.conf) Installing Angstrom on BeagleBoard-xM A.3.1 Getting the files needed for installation A.3.2 Setting the MMC for installation A.3.3 Copying the image files to MMC 74 75 81 81 82 84

2011

Appendix-B …………………………………………………………………………...86 B.1 B.2 Sample Application Installation of DSPLINK B.2.1 Cross Compiling TI packages B.2.2 Installiung TI packages on target platform B.2.3 Setting up DSPLink Frameworkfor GPP/DSP Applications B.3 Installation of C6Run B.3.1 Stand alone Download B.3.1.1 Stand alone Setup 104 109 110 111 115 86 90 90 92

B.3.2 Steps for running C6Run programs on target platform B.3.3 How to make your own C6Run appicationusing C6Run Makefiles

117

vi

Importing Open-BTS Software on BeagleBoard List of Tables

2011

Table 3-1, Features of BeagleBoard-xM ……………………………………………….…...11 Table 5-1, DSP/BIOS Modules ……………………………………………….………….....22

vii

Importing Open-BTS Software on BeagleBoard List of Figure

2011

FIGURE 1-1: Block diagram of typical SDR system …………………………………………....1 FIGURE 1-2: Block Diagram of the Open-BTS network ……………….……………………....3 FIGURE 3-1 BeagleBoards C4 and –Xm ……………………………………………………...10 FIGURE 5-1 Typical flow of DSP/BIOS Application ………….…………………………........24 FIGURE 5-2 Software architecture of DSP/BIOS LINK …………………………………….....27 FIGURE 5-3 App Scenario: Static buffer system with minimal controlcommunication with the DSP ………………………………….....39 FIGURE 5-4 App Scenario: Dynamic buffer system with minimal controlcommunication with the DSP ………………………………….....40 FIGURE 5-5 App Software Scenario: Multiple buffers to be sent between GPP and DSP …………………………………………….....…....42 FIGURE 5-6 Normal Boot Mode …………………………………………………………….....44 FIGURE 5-7 External Load Mode …………………………………………………..….……......45 FIGURE 5-8 External Load And Start Mode …...….………………………………..….…….....46 FIGURE 5-9 Codec Engine GPP/DSP Programming Approach ………………………....…...48 FIGURE 5-10 C6RUNLIB …………………………………………………………….....…….51 FIGURE 5-11 C6RUNAPP ……………………………………………………………....…....54 FIGURE 6-1 GPP/DSP Message Format ……………………………………………...….....…62 FIGURE 6-2 The Programming Flow Between GNURadio,GPP Libraryand DSP Executable …………………………………...…....…64 FIGURE 6-3 DSP Based GNURadio Block Abstraction ……………………………...…....…64 FIGURE A-1 Command action of fdisk ……………………………...…...…………………...83 FIGURE B-1 Data flow in the sample application-LOOP …………….......…………………...86

viii

Importing Open-BTS Software on BeagleBoard List of Symbols and Abbreviations
SDR GPP DSP FPGA USRP DAC ADC RF PBX VOIP BSC MSC GPRS UMTS CDMA BTS OE TI OS GCC SoC Software Defined Radio General Purpose Processor Digital Signal Processor Field Programmable Gate Arrays Universal Software Radio Peripheral Digital to Analog Converter Analog to Digital Converter Radio Frequency Private Branch Exchange Voice Over Internet Protocol Base Station Controller Mobile Switching Center General Packet Radio Service Universal Mobile Telecommunications System Code Division Multiple Acces Base Tranceiver Station OpenEmbedded Texas Instruments Operating System GNU Compiler Collection System-on-Chip
ix

2011

Importing Open-BTS Software on BeagleBoard
API FIR FFT Application Programming Interface Frequency Impulse Response Fast Fourier Transform

2011

x

Importing Open-BTS Software on BeagleBoard Acknowledgement

2011

We would like to thank Dr. Hazem Nassef and Dr. Almohanad S. fayez (Virginia Tech.) for their contribution to the work that is shown in this document, and for their support. We would also like to thank our Supervisor Prof.Dr. Magdi Fikri for giving us the opportunity to be part of a great project as this one. We would also like to thank the faculty members for their effort in making the institution a well established environment for learning.

xi

Importing Open-BTS Software on BeagleBoard Abstract

2011

This project is a part of a bigger project known as Open-BTS whose purpose is to implement the first open-source software defined industry-standard GSM network. Our project is called "Importing Open-BTS software on BeagleBoard". The idea behind this project is to introduce a lower cost, smaller size, lower power consuming and less real-time processing platform than traditional PC's and laptops. This is done through modifying the software of Open-BTS to be implemented on BeagleBoard which has an OMAP3530 processer that contains a DSP and a GPP among which the processing can be distributed to optimize the processing time.

xii

Importing Open-BTS Software on BeagleBoard BTS Chapter 1 : Introduction

2011

The Open-BTS project is an application on SDR that performs the task of Base BTS applica Transceiver Station (BTS) and some more functionalities of a cellular mobile network. So before we go in depth with the Open-BTS project we have to discuss Open oject what is SDR.

1.1 Software Defined Radio: One of the SDR definitions is "Radio in which some or all of the physical layer functions are software defined". It can be imagined as a radio system that can operate on different spectrum regions with any standard using the same hardware, simply by changing the running software. Traditional hardware based radio limits the cross-functionality and can only be functionality modified or upgraded by changing or adding new hardware. SDR technology provides more flexibility, lower cost and easier way to modify and/or upgrade the system through modifying the software with keeping the hardware unchanged. hardwa SDR defines a collection of hardware and software technologies where some or all of the required functionalities are implemented through software or programmable processing devices such as FPGA, DSP and GPP. Finally, the use of SDR technology allows adding new features and capabilities to existing radio systems without requiring new hardware.

1.2 The Basic Architecture of SDR system:

Fig.1-1, Fig.1 Block diagram of typical SDR system

1

Importing Open-BTS Software on BeagleBoard

2011

In the previous Figure (Fig.1-1) we can see the block diagram of a typical SDR system where the User Defined Code is implemented on PC or any other platform is responsible for the baseband processing. The hardware block represents the hardware part of the radio system (USRP in case of Open-BTS project) it includes the DAC/ADC and some other blocks. Finally, there is the RF front end that is responsible for transmitting or receiving signals. As shown in figure, When the system is operating as transmitter the flow of the data is from the PC through the system hardware to the RF front end, while when the system is operating as receiver the data is received by the RF front end passes through the system hardware and then the processing is done by the PC.

1.3 Open-BTS:

Now that we know what SDR is, we can move on explaining the Open-BTS project. Open-BTS is a software-defined GSM network access point that allows existing standard GSM compatible mobile stations to make phone calls without using the existing telecommunication service providers' networks. Open-BTS is the first free open source software implementation of the industry-standard GSM protocol stack. OpenBTS is an open-source Unix application that uses the USRP to present a GSM air interface ("Um") to standard GSM handset and uses the Asterisk® software PBX to connect calls. The combination of the ubiquitous GSM air interface with VoIP backhaul could form the basis of a new type of cellular network that could be deployed and operated at substantially lower cost than existing technologies in greenfields in the developing world. Open-BTS is in fact very different from a conventional GSM BTS, which is a dumb device that is managed externally by BSC and connects calls in a remote MSC. Because of this important architectural difference, the end product of this project is better referred to as an access point, even though the project is called “Open-BTS”.

2

Importing Open-BTS Software on BeagleBoard BTS

2011

Future versions of the Open Open-BTS may well support GPRS and EDGE. t GPRS, when available, should be a software only upgrade for any installe Opensoftware-only installed BTS system. EDGE supp support may require additional computat computational resources but the additional software is not complex, at least when compared to the rest of the BTS. UMTS is a radically different CDMA-style physical layer and well CDMA style outside the current scope of this project. David Burgess and Harvind Samra the founders of Kestrel Signal Processing are the ones who developed the code its very beginning in August of 2007, they believe that they could re re-use the GSM handsets and its basic infrastructure to address the last remaining market, which is the three billion poorest people on Earth, who will not get telephone service otherwise. They will not get telephone service at $6 a month because they simply cannot afford it and so they would like to offer it ause in the range of $1 a month. The end product of this application is a complete network that supports a full GSM network enabli complete enabling telephone calls, sending and receiving text messages, having a mailbox, transferring data (on upgrading to GPRS or EDGE) and it could even be connected to the local phone network and so could make external calls using the call local phone network, as shown in Fig.(1-2) Fig.(1

Fig.1-2, Block Diagram of the Open-BTS network Fig.

3

Importing Open-BTS Software on BeagleBoard
1.4 Current Work in the Open-BTS project:

2011

Currently work is being done to enhance and improve the Open-BTS project through the following five approaches: 1. Importing the Open-BTS software to BeagleBoard-xM. 2. Using antenna couplers to use one antenna as transmitter and receiver. 3. Multiband processing: Improving the system to operate in both 900/1800 MHz ranges. 4. Reducing the co-channel interference. Our group is working on the first approach (Importing the OpenBTS software on BeagleBoard) which will be discussed throughout this documentation. Through this approach we are trying to use the BeagleBoard instead of the Personal Computer (PC) to host the software part of the project. The reason for choosing the BeagleBoard is reducing the power consumption, size, cost and time needed for real-time processing through using the DSP/GPP integrated on the BeagleBoard. The software OpenBTS is a C/C++ and Python coded application that uses the GNU Radio blocks. This software is responsible for performing all the processing needed in the system on the host PC or hopefully the BeagleBoard.

4

Importing Open-BTS Software on BeagleBoard Chapter 2: GNU Radio and Python

2011

2.1 GNU Radio:

GNU Radio is an open SDR project. The main idea behind this project, as its founder says, was to turn all the hardware problems into software problems, that is to move the complexity of a radio equipment from the hardware level to the software one, and get the software as close to the antenna as possible. GNU Radio is a free software development toolkit which allows developing a custom non commercial radio receiver just by combining and interconnecting appropriate software modules , as if they were functional blocks (the package include about 100 modules, but others can be added to the initial library). Each module is able to perform a specific signal processing function (for example a mixer, a phase lock loop, a filter), with a real-time behavior and with highthroughput; for this reason, a recent PC with enough processing capability and memory should be used. With the GNU Radio approach, the designer is a software developer who builds the radio by creating a graph (in a similar way to what happens in the graph theory) where the vertices are signal processing blocks and the edges represent the data flow between them. The signal processing blocks are normally implemented in C++, whereas the graph structure is defined in Python. GNU Radio software modules support various modulation schemes (GMSK, PSK, QAM, OFDM), error corrections codes (Reed-Solomon, Viterbi, Turbo Codes), and signal processing capabilities (filters, FFTs, equalizers, timing recovery). GNU Radio applications (e.g. Open-BTS) are mainly written in Python; however, the critical and low-level algorithms and signal processing modules are written using the C/C++ programming language, with wide usage of floating-point specific instructions for the relevant processor. Python is primarily used to setup the flow graph, after that most of the work is done in C/C++. GNU Radio is simple to use and a radio receiver can be created in a fast and straight forward manner; moreover, the development of a signal processing algorithm can be carried out using a pre-recorded or generated data set, thus allowing the development without

5

Importing Open-BTS Software on BeagleBoard

2011

the need for a real RF hardware. An example of minimal hardware required to work with GNU Radio is offered by the USRP.

2.1.1 How to write signal processing blocks in GNU Radio

For information on how to write signal processing blocks that will be used in Dr. Almohanad's LoopAl2 sample to send GNU Radio code from the GPP to the DSP which will be described later in chapter 6 follow this link: http://www.gnu.org/software/gnuradio/doc/howto-write-a-block.html

2.2 Python 2.2.1 Python programming language Overview

Python is an easy to learn, powerful programming language. It has efficient highlevel data structures and a simple but effective approach to object-oriented programming. Python’s elegant syntax and dynamic typing, together with its interpreted nature, make it an ideal language for scripting and rapid application development in many areas on most platforms. Python interpreter is easily extended with new functions and data types implemented in C or C++ (or other languages callable from C). Python is also suitable as an extension language for customizable applications. Python is simple to use, but it is a real programming language, offering much more structure and support for large programs than shell scripts or batch files can offer. On the other hand, Python also offers much more error checking than C, and, being a very-high-level language, it has high-level data types built in, such as flexible arrays and dictionaries. Because of its more general data types Python is applicable to a much larger problem domain than Awk or even Perl, yet many things are at least as easy in Python as in those languages. It allows you to split your program into modules that can be reused in other Python programs, and comes with a large collection of standard modules that you can use as the basis of your programs — or as examples to start learning to
6

Importing Open-BTS Software on BeagleBoard

2011

program in Python. Some of these modules provide things like file I/O, system calls, and sockets. Python is an interpreted language, which can save you considerable time during program development because no compilation and linking is necessary. The interpreter can be used interactively, which makes it easy to experiment with features of the language, to write throw-away programs, or to test functions during bottom-up program development. Signal processing blocks in GNU Radio are written in Python, So Python plays a main role in developing Flow Graphs and applications of GNU Radio. In the next part we’ll focus on the role of Python programming language in GNU Radio.

2.2.2 Python VS GNU Radio

GNU Radio provides a framework for building software radios. Waveforms -signal processing applications -- are built using a combination of Python code for high level organization, policy, GUI and other non performance-critical functions, while performance critical signal processing blocks are written in C++. From the Python point of view, GNU Radio provides a data flow abstraction. The fundamental concepts are signal processing blocks and the connections between them. This abstraction is implemented by the Python gr.flow_graph class. Each block has a set of input ports and output ports. Each port has an associated data type. The most common port types are float and gr_complex (equivalent to std::complex<float>), though other types are used, including those representing structures, arrays or other types of packetized data. From the high level point-of-view, infinite streams of data flow through the ports. At the C++ level, streams are dealt with in convenient sized pieces, represented as contiguous arrays of the underlying type. Blocks that are used in GNU Radio can be imported using import mechanism, but in case that these blocks are not loaded in Python they are built outside of the gnuradio-core build tree, and are constructed as shared libraries that may be dynamically loaded into Python using the "import" mechanism. SWIG, the Simplified Wrapper and Interface Generator, is used to generate the glue that allows our code to be used from Python.
7

Importing Open-BTS Software on BeagleBoard

2011

Python provides at least three different ways to import modules. You can use the import statement, the from statement, or the builtin __import__ function. 1. import X imports the module X, and creates a reference to that module in the current namespace. Or in other words, after you’ve run this statement, you can use X.name to refer to things defined in module X. 2. from X import * imports the module X, and creates references in the current namespace to all public objects defined by that module or in other words, after you’ve run this statement, you can simply use a plain name to refer to things defined in module X. But X itself is not defined, so X.name doesn’t work. And if name was already defined, it is replaced by the new version. And if name in X is changed to point to some other object, your module won’t notice. 3. from X import a, b, c imports the module X, and creates references in the current namespace to the given objects. Or in other words, you can now usea and b and c in your program. 4. Finally, X = __import__(‘X’) works like import X, with the difference that you 1) pass the module name as a string, and 2) explicitly assign it to a variable in your current namespace.

2.2.3 What does Python do to import a module?

When Python imports a module, it first checks the module registry (sys.modules) to see if the module is already imported. If that’s the case, Python uses the existing module object as is. Otherwise, Python does something like this: 1. Create a new, empty module object. 2. Insert that module object in the sys.modules dictionary. 3. Load the module code object.
8

Importing Open-BTS Software on BeagleBoard

2011

4. Execute the module code object in the new module’s namespace. All variables assigned by the code will be available via the module object. This means that it’s fairly cheap to import an already imported module; Python just has to look the module name up in a dictionary. There is also connect function that’s used to connect signal processing blocks together.

9

Importing Open-BTS Software on BeagleBoard Chapter 3: BeagleBoard-xM

2011

3.1 What is BeagleBoard?

The BeagleBoard is designed specifically to address the Open Source Community. It has been equipped with a minimum set of features to allow the user to experience the power of the processor and is not intended as a full development platform as many of the features and interfaces supplied by the processor are not accessible from the BeagleBoard. By utilizing standard interfaces, the BeagleBoard is highly extensible to add many features and interfaces. It is not intended for use in end products.
3.2 BeagleBoard Versions

There are two different versions of the beagle in production, the Rev C4 and the – xM. Figure.(3-1) is a picture of each of these versions. We are interested in the – xm Version only. As it has more features than the Rev C4.

Fig.3-1, BeagleBoards C4 and -xM

10

Importing Open-BTS Software on BeagleBoard
3.3 BeagleBoard Specifications 3.3.1BeagleBoard Features

2011

The next table shows the main features of BeagleBoard-xM Table.(3-1), Features of BeagleBoard-xM
Processor POP Memory PMIC TPS65950

Texas Instruments Cortex A8 1GHz processor Micron 4Gb MDDR SDRAM (512MB) 200MHz Power Regulators Audio CODEC Reset USB OTG PHY

Debug Support PCB Indicators HS USB 2.0 OTG Port USB Host Ports

14-pin JTAG UART 3.1” x 3.0” (78.74 x 76.2mm) Power, Power Error PMU Mini AB USB connector TPS65950 I/F

GPIO Pins 3 LEDs 6 layers 2-User Controllable USB Power

SMSC LAN9514 Ethernet HUB 4 FS/LS/HS Up to 500ma per Port if adequate power is supplied From USB HUB 3.5mm L+R Stereo In

Ethernet Audio Connectors SD/MMC Connector

10/100 3.5mm L+R out MicroSD

11

Importing Open-BTS Software on BeagleBoard
User Interface Video Camera Power Connector Overvoltage Protection Main Expansion Connector

2011

1-User defined button DVI-D Connector USB Power

Reset Button S-Video Supports Leopard Imaging Module DC Power

Shutdown @ Over voltage Power (5V & 1.8V) McBSP I2C MMC2 Access to all of the LCD control signals plus I2C MMC3 UART McSPI GPIO PWM 3.3V, 5V, 1.8V

2 LCD Connectors

Auxiliary Audio 4 pin connector Auxiliary Expansion

McBSP2 MMC3,GPIO,ADC,HDQ

The following sections provide more detail on Processor, Memory and Power management.

3.3.2 Processor:

The BeagleBoard-xM processor is the DM3730CBP 1GHz version and comes in a 4mm pitch POP package. POP (Package on Package) is a technique where the memory is mounted on top of the processor. For this reason, when looking at the BeagleBoard, you will not find an actual part labeled DM3730CBP, but instead see the part number for the memory.

12

Importing Open-BTS Software on BeagleBoard
3.3.3 Memory:

2011

There are two possible memory devices used on the –xM. The -00 assembly uses the Micron POP memory and the -01 uses the Numonyx POP memory. The key function of the POP memory is to provide: 4Gb MDDR SDRAM x32 (512MB @ 166MHz). No other memory devices are on the BeagleBoard. It is possible however, that additional non volatile memory storage can be added to BeagleBoard by: 1. Accessing the memory on the uSD card. 2. Use the USB OTG port and a powered USB hub to drive a USB Thumb drive or hard drive. 3. Install a thumb-drive into one of the USB ports. 4. Add a USB to Hard Disk adapter to one of the USB ports. Support for these devices is dependent upon driver support in the OS.

3.3.4 Power Management:

The TPS65950 is used on the BeagleBoard to provide power with the exception of a 3.3V regulator which is used to provide power to the DVI-D encoder and RS232 driver and an additional 3.3V regulator to power the USB Hub. In addition to the power the TPS65950 also provides: 1. Stereo Audio Out. 2. Stereo Audio in. 3. Power on reset. 4. USB OTG PHY. 5. Status LED. It needs a supply with 5v. The choice of BeagleBoard-xM based on its features as it saves power and also due to its speed, in addition to small size. In order to make BeagleBoard ready to be used there are some procedures that should be taken into consideration that would be discussed later.

13

Importing Open-BTS Software on BeagleBoard Chapter 4: Tools needed to start working BeagleBoard

2011

The first thing you need to have installed on your BeagleBoard is an operating system. We have chosen Angstrom-2010 to be the operating system to use because it has an existing support for GNU Radio and USRP. There are many websites from which you can download your Angstrom-2010 image such as http://narcissus.angstrom-distribution.org/. But it is preferable to build your own image by yourself using the cross-compilation environment called OE; this way you can choose the packages you need and neglect those you don’t. Also you can use the OE environment with Bitbake to build any packages you might need later on (e.g. GNU Radio and TI tool kits) and add packages that you have written by yourself.

4.1 OpenEmbedded:

The OE Project is a software framework to create Linux distributions aimed for, but not restricted to, embedded devices. It was created by Chris Larson, Michael Lauer, and Holger Schurig. OE is a set of metadata used to cross-compile, package and install software packages. OE is being used to build and maintain a number of embedded Linux distributions, including OpenZaurus, Ångström, Familiar and SlugOS. The primary use-cases of OE are:
• • • • •

Handle cross-compilation. Handle inter-package dependencies. Ability to emit packages (tar, rpm, deb, ipk). Ability to create images and feeds from packages. Highly configurable to support many machines, distributions and architectures. • Easy and reusable writing of metadata.

14

Importing Open-BTS Software on BeagleBoard
4.1.1 Installation of OE:

2011

Before downloading OE you will have to decide where on your system you would like to work. Then, you should export an environment variable ($OEBASE) to point to that directory e.g. OEBASE=/home/<user_name>/oe. Steps to download OE: 1) Create the directory structure:

$ mkdir -p $OEBASE/build/conf $ cd $OEBASE

• The “build” directory will contain the configuration files.

2) Obtaining Bitbake (the build tool for OE):

$ $ $ $

cd $OEBASE wget http://download.berlios.de/bitbake/bitbake-1.8.18.tar.gz tar -xvzf bitbake-1.8.18.tar.gz mv bitbake-1.8.18 bitbake

3) Getting OE: OE is a Git repository so if you don’t have Git installed on your system you have to install it before downloading OE by typing
$ sudo apt-get install git

Downloading OE:
$ cd $OEBASE $ git clone git://git.openembedded.org/openembedded

15

Importing Open-BTS Software on BeagleBoard

2011

OE is updated very frequently so it would be better if you update your OE every couple of days using the following command:
$ cd $OEBASE/openembedded $ git pull

4.1.2 Building Distributions with OE:

To start building images and packages with OE you will have to set some environment variables and edit the configuration file “local.conf” look in appendix-A. After setting the environment and editing the configuration file you can start building your image or whatever packages you want by the OE building tool Bitbake which will be discussed in the following section (4.2).

4.2 Bitbake:

Bitbake is the building tool for OE. Like any build tool (e.g. make) Bitbake controls how packages are built and the build dependencies, But unlike single project build tools it is not based on one makefile or a closed set of inter-dependent makefiles, but collects and manages an open set of largely independent build descriptions (package recipes) and builds them in proper order. Important features of BitBake are:
• Handle cross-compilation. • Handle interpackage dependencies (build time on target architecture, build time on native architecture, and runtime).

16

Importing Open-BTS Software on BeagleBoard

2011

• Support running any number of tasks within a given package, including (but not limited to) fetching upstream sources, unpacking them, patching them and configuring them. • Both build and target must be linux distributions. • Supports multiple build and target operating systems (including cygwin, the BSDs, etc). • Ability to be self contained, rather than tightly integrated into the build machine's root filesystem. • It has a way to handle conditional metadata (on target architecture, operating system, distribution, and machine). • Easy for the person using the tools to supply their own local metadata and packages to operate against. • Easy to collaborate between multiple projects using BitBake for their builds. • Provides an inheritance mechanism to share common metadata between many packages.

4.2.1 Usage of Bitbake:

You can know the usage of Bitbake in details by typing
$ bitbake --help

Or from the manual pages by typing
$ man bitbake

But here we will point out the most important uses of bitbake: 1) Building a single package:
$ bitbake –b <path_to_the_package_recipe>/<package_name>.bb

17

Importing Open-BTS Software on BeagleBoard

2011

2) Building a complete image: There are many image types but we are interested in the smallest possible console image and the image that supports GUI. The commands to build the above mentioned images are: a. Console image:
$ bitbake base-image

b. GUI image:
$ bitbake x11-image

3) Make the bitbake do as much tasks as possible and not to stop when an error occurs
$ bitbake –k <target_recipe>

4) If you want to clean your work for whatever reason (e.g. the build was interrupted and you need to start over) type this command:
$ bitbake –c clean <task>

Bitbake will create a directory called “tmp” in the current directory you were standing into when you typed the command. This directory will contain the all the work done by bitbake. The output of your work will be found in the path “…./tmp/deploy/eglibc”.
Note: The build process might take a very long time (>24 hours) and it needs a connection to the internet.
18

Importing Open-BTS Software on BeagleBoard
4.2.2 Writing your own recipe:

2011

Recipes are the files that tell Bitbake how to build the package and what tasks to do (like makefiles for GNU make). In these recipes you define the version of the package you want to build, the dependencies for this package, the files needed to be downloaded and where to download them, the recipes to inherit (if exists) and the tasks to be done (e.g. fetch, compile , configure, install, package, patch, etc.). You can learn the syntax of the recipes and how to write them from the bitbake user manual http://bitbake.berlios.de/manual/.

19

Importing Open-BTS Software on BeagleBoard Chapter 5: GPP/DSP communication tools

2011

In this part we will give an overview of DSPBIOS, DSP/BIOS™ LINK and information about the various concepts and components in DSP/BIOS™ LINK along with their features, concepts and programming tips.

5.1 DSP/BIOS ( operating system running on the DSP )

DSP/BIOS is a scalable real-time kernel. It is designed to be used by applications that require real-time scheduling and synchronization, host-to target communication, or real-time instrumentation. DSP/BIOS provides preemptive multi-threading, hardware abstraction, real-time analysis, and configuration tools.
5.1.1 DSP/BIOS Features

DSP/BIOS is designed to minimize memory and CPU requirements on the target. This design goal is accomplished in the following ways: • All DSP/BIOS objects can be configured statically and bound into an executable program image. This reduces code size and optimizes internal data structures. • Instrumentation data (such as logs and traces) are formatted on the host. • The APIs are modularized so that only those APIs that are used by the program need to be bound into the executable program. • The library is optimized to require the smallest possible number of instruction cycles, with a significant portion implemented in assembly language. • Communication between the target and DSP/BIOS analysis tools is performed within the background idle loop. This ensures that DSP/BIOS analysis tools do not interfere with the program’s tasks. If the target CPU is too busy to perform background tasks, the DSP/BIOS analysis tools stop receiving information from the target until the CPU is available. • Error checking that would increase memory and CPU requirements has been kept to a minimum. Instead, the API reference documentation specifies
20

Importing Open-BTS Software on BeagleBoard

2011

constraints for calling API functions. It is the responsibility of the application developer to meet these constraints. In addition, the DSP/BIOS API provides many options for program development: • A program can dynamically create and delete objects that are used in special situations. The same program can use both objects created dynamically and objects created statically. • The threading model provides thread types for a variety of situations; hardware interrupts, software interrupts, tasks, idle functions, and periodic functions are all supported. You can control the priorities and blocking characteristics of threads through your choice of thread types. • Structures to support communication and synchronization between threads are provided. These include semaphores, mailboxes, and resource locks. • Two I/O models are supported for maximum flexibility and power. Pipes are used for target/host communication and to support simple cases in which one thread writes to the pipe and another reads from the pipe. Streams are used for more complex I/O and to support device drivers. • Low-level system primitives are provided to make it easier to handle errors, create common data structures, and manage memory usage. The DSP/BIOS API standardizes DSP programming for a number of TI devices and provides easy-to-use powerful program development tools. These tools reduce the time required to create DSP programs in the following ways: • The Tconf configuration script generates code required to statically declare objects used within the program. • The configuration detects errors earlier by validating properties before the program is built. • Configuration scripts can be modified in a text editor to include branching, looping, testing of command-line arguments and more. • Logging and statistics for DSP/BIOS objects are available at run-time without additional programming. Additional instrumentation can be programmed as needed. • The DSP/BIOS analysis tools allow real-time monitoring of program behavior.
21

Importing Open-BTS Software on BeagleBoard

2011

• DSP/BIOS provides a standard API. This allows DSP algorithm developers to provide code that can be more easily integrated with other program functions. 5.1.2 DSP/BIOS API

The DSP/BIOS API is divided into modules which are included in Table. (5-1). Depending on what modules are configured and used by the application, the size of DSP/BIOS can range from about 500 to 6500 words of code. All the operations within a module begin with the letter codes. Application programs use DSP/BIOS by making calls to the API. All DSP/BIOS modules provide C-callable interfaces. Most C-callable interfaces can also be called from assembly language, provided that C calling conventions are followed. Some of the C interfaces are actually C macros and therefore, cannot be used when called from assembly language. Refer to the TMS320 DSP/BIOS API Reference Guide for your platform for details. Table. (5-1), DSP/BIOS Modules
Module ATM BUF C28, C54, C55, C62, C64 CLK DEV GBL GIO HOOK HST HWI IDL LCK LOG Description Atomic functions written in assembly language Fixed-length buffer pool manager Target-specific functions, platform dependent Clock manager Device driver interface Global setting manager General I/O manager Hook function manager Host channel manager Hardware interrupt manager Idle function manager Resource lock manager Event log manager
22

Importing Open-BTS Software on BeagleBoard
MBX MEM MSGQ PIP POOL PRD PWRM QUE RTDX SEM SIO STS SWI SYS TRC TSK Mailbox manager Memory segment manager Message queue manager Buffered pipe manager Allocator pool manager Periodic function manager Power manager (C55x only) Atomic queue manager Real-time data exchange settings Semaphore manager Stream I/O manager Statistics object manager Software interrupt manager System services manager Trace manager Multitasking manager

2011

5.1.3 DSP/BIOS Configuration

A DSP/BIOS configuration allows you to optimize your application by creating objects and setting their properties statically, rather than at run-time. This both improves run-time performance and reduces the application footprint. The source file for a configuration is a DSP/BIOS Tconf script, which can be edited using a text editor, you can write the configuration using JavaScript syntax. You can set a wide range of parameters used by DSP/BIOS at run time. The objects you create are used by the application DSP/BIOS API calls. These objects include software interrupts, tasks, I/O streams, and event logs. When you save a configuration, Tconf generates files to be included in the project. Using static configuration, DSP/BIOS objects can be pre-configured and bound into an executable program image. Alternately, a DSP/BIOS program can create and delete certain objects at run time.

23

Importing Open-BTS Software on BeagleBoard

2011

In addition to minimizing the target memory footprint by eliminating run-time code and optimizing internal data structures, creating static objects detects errors earlier by validating object properties before program compilation.
5.1.3.1 Files Used to Create DSP/BIOS Programs

Fig. (5-1), shows files used to create DSP/BIOS applications. Files you write are shown with a white background; generated files have a gray background. The word "program" represents the name of your project or program. The number 54 is replaced by 28, 55, or 64 as appropriate for your platform.

Fig. 5-1. Typical flow of DSP/BIOS Applications

5.1.3.1.1 Program Files • program.c. Program source file containing the main function. You can also have additional .c source files and program .h files. • program.tcf. The Tconf script that generates the configuration files when run. This is the source file for the configuration. This is the file you add to a Code Composer Studio project to make the configuration part of the application.

24

Importing Open-BTS Software on BeagleBoard

2011

• *.asm. Optional assembly source file(s). One of these files can contain an assembly language function called _main as an alternative to using a C or C++ function called main. • module.h. DSP/BIOS API header files for C or C++ programs. Your source files should include std.h and the header files for any modules the program uses. 5.1.3.1.2 Files Used to Create DSP/BIOS Programs • module.h54. DSP/BIOS API header files for assembly programs. Assembly source files should include the *.h54 header file for any module the assembly source uses. • program.obj. Object file(s) compiled or assembled from your source file(s). • *.obj. Object files for optional assembly source file(s). • *.cmd. Optional linker command file(s) that contains additional sections for your program not defined by the DSP/BIOS configuration. • program.out, An executable program for the target (fully compiled, assembled, and linked). 5.1.3.1.3 Static Configuration Files

When you run a Tconf script that contains the prog.gen() method, the following files are created (where "program" is the configuration file name and 54 is replaced by 28, 55, or 64 as appropriate for your platform): • programcfg.cmd. Linker command file for DSP/BIOS objects. This file defines DSP/BIOS-specific link options and object names, and generic data sections for DSP programs (such as .text, .bss, .data, etc.). When you add a *.tcf file to a Code Composer Studio project, this file is automatically added in the Generated Files folder of the Project View. • programcfg.h. Includes DSP/BIOS module header files and declares external variables for objects created in the configuration. • programcfg_c.c. Defines DSP/BIOS related objects. (No longer defines CSL objects.)
25

Importing Open-BTS Software on BeagleBoard

2011

• programcfg.s54. Assembly language source file for DSP/BIOS settings. When you add a *.tcf file to a Code Composer Studio project, this file is automatically added in the Generated Files folder of the Project View. • programcfg.h54. Assembly language header file included by programcfg.s54. • program.cdb. Stores configuration settings for use by run-time analysis tools. In previous versions, this was the configuration source file. It is now generated by running the *.tcf file. This file is used by the DSP/BIOS analysis tools. • programcfg.obj. Object file created from the source file generated by the configuration. Hint: DSP/BIOS 6 uses RTSC configuration script not Tconf scripts but as DSP/BIOS LINK uses DSP/BIOS 5 that in turn uses Tconf, not RTSC, so in this project we will not talk about RTSC, for tutorials about RTSC you can visit: http://rtsc.eclipse.org/docs-tip/Introducing_RTSC

A conversion utility is provided to translate Tconf configurations to RTSC configurations, explained in Migrating a DSP/BIOS 5 Application to DSP/BIOS 6 (SPRAAS7B) manual released by Texas Instruments.
5.2 DSP/BIOS™ LINK

DSP/BIOS™ LINK is foundation software for the inter-processor communication across the GPP-DSP boundary. It provides a generic API that abstracts the characteristics of the physical link connecting GPP and DSP from the applications. It eliminates the need for customers to develop such link from scratch and allows them to focus more on application development. This software can be used across platforms: • Using SoC with GPP and one DSP. • With discrete GPP and DSP.

26

Importing Open-BTS Software on BeagleBoard

2011

As the name suggests, DSP/BIOS™ is expected to be running on the DSP. No specific operating system is mandated to be running on the GPP. It is released on a reference platform for a set of reference operating systems. The release package contains full source code to enable the customers to port it to their specific platforms and/or operating systems. Depending on the supported platform and OS, DSP/BIOS™ LINK provides a subset of the following services to its clients: • Basic processor control • Shared/synchronized memory pool across multiple processors • Notification of user events • Mutually exclusive access to shared data structures • Linked list based data streaming • Data transfer over logical channels • Messaging (based on MSGQ module of DSP/BIOS) • Ring buffer based data streaming The Zero Copy Messaging mechanism may be used for messaging. A typical application may not require all services provided by DSP/BIOS™ LINK. Also, a typical application may use only one mechanism for transferring messages between GPP and DSP. To enable this capability, DSP/BIOS™ LINK can be scaled at compile time to choose only the required components.
5.2.1 Overview The software architecture of DSP/BIOS™ LINK is shown in the diagram below Fig. (5-2).

Fig. 5-2. Software architecture of DSP/BIOS™ LINK

27

Importing Open-BTS Software on BeagleBoard
5.2.1.1 On the GPP side

2011

On the GPP side, a specific OS is assumed to be running. • The OS ADAPTATION LAYER encapsulates the generic OS services that are required by the other components of DSP/BIOS™ LINK. This component exports a generic API that insulates the other components from the specifics of an OS. All other components use this API instead of direct OS calls. This makes DSP/BIOS™ LINK portable across different operating systems. • The LINK DRIVER encapsulates the low-level control operations on the physical link between the GPP and DSP. This module is responsible for controlling the execution of the DSP and data transfer using defined protocol across the GPP-DSP boundary. • The PROCESSOR MANAGER maintains book-keeping information for all components. It also allows different boot-loaders to be plugged into the system. It builds exposes the control operations provided by the LINK DRIVER to the user through the API layer. • The DSP/BIOS™ LINK API is interface for all clients on the GPP side. This is a very thin component and usually doesn’t do any more processing than parameter validation. The API layer can be considered as ‘skin’ on the ‘muscle’ mass contained in the PROCESSOR MANAGER and LINK DRIVER. The thin API layer allows easy partition of DSP/BIOS™LINK across the user kernel boundary on specific operating systems e.g. Linux. Such partition may not be necessary on other operating systems.
5.2.1.2 On the DSP side

Here, the LINK DRIVER is one of the drivers in DSP/BIOS™. This driver specializes in communicating with the GPP over the physical link. The communication (data/ message transfer) is done using the DSP/BIOS™ modulesSIO/ GIO/ MSGQ. There are specific DSP/BIOS™ LINK API on the DSP for the other modules RingIO, MPCS, MPLIST, NOTIFY, POOL.

28

Importing Open-BTS Software on BeagleBoard

2011

In the following section we will talk about the main components that most DSPLINK applications use, illustrating various steps involved in Initialization, Execution and Finalization phases of each component.
5.2.2 Key Components 5.2.2.1 PROC

This component represents the DSP processor in the application space. PROC is an acronym for ‘processor’. This component provides services to: • Initialize the DSP & make it available for access from the GPP. • Load code on the DSP. • Start execution from the run address specified in the executable. • Read from or write to DSP memory. • Stop execution. • Additional platform-specific control actions. • Get DSP address for given symbol. In the current version, only one processor is supported. However, the APIs are designed to support multiple DSPs and hence they accept a processor Id argument to support this future enhancement.
5.2.2.1.1 INITIALIZATION

1. Do the basic initialization of the component. This initialization sequence extends to the lower level components and populates the necessary data structures. 2. Attach to the specific DSP for communication. In the process, the lower level components initialize the hardware interfacing the DSP to make it accessible to the GPP. 3. Load an executable on the DSP. This executable contains the application intended to run on the DSP. The client that attaches first to a DSP becomes the owner of the DSP. Such
29

Importing Open-BTS Software on BeagleBoard

2011

ownership model is required so that another client doesn’t cause undesirable side affects e.g. stop the DSP/ load another executable etc. APIs used 1. PROC_setup () 2. PROC_attach () 3. PROC_load () 5.2.2.1.2 EXECUTION

1. Start execution of the executable that was loaded earlier on the DSP. Once the DSP is executing, there isn’t much expected from the PROC component. 2. Read from DSP memory. 3. Write to DSP memory. 4. Once the application completes, the execution is stopped.
Relevant APIs 1. PROC_start () 2. PROC_read () 3. PROC_write () 4. PROC_stop () 5.2.2.1.3 FINILIZATION

1. Detach from the DSP. If the client was the owner of the DSP (i.e. was the first to attach to the DSP) then it also finalizes the DSP. 2. Free the resources allocated in the initialization phase.
Relevant APIs 1. PROC_detach () 2. PROC_destroy () The PROC component must be the last one to be finalized by the application.
30

Importing Open-BTS Software on BeagleBoard
5.2.2.2 POOL

2011

This component provides APIs for configuring shared memory regions across processors. It also provides APIs for synchronizing the contents of buffer as seen by the two CPU cores. These buffers are used by other modules from DSP/BIOS Link for providing interprocessor communication functionality. These can also be used by applications for implementing their own protocol for data streaming if desired. The specific services provided by this module are: 1. Configure the shared memory region through open & close calls. 2. Allocate and free buffers from the shared memory region. 3. Translate address of a buffer allocated to different address spaces (e.g. GPP to DSP) 4. Synchronize contents of memory as seen by the different CPU cores. This component is responsible for providing a uniform view of different memory pool implementations, which may be specific to the hardware architecture or OS on which DSP/BIOS™ LINK is ported. This component is based on the POOL interface in DSP/BIOS™.
5.2.2.2.1 INITIALIZATION

Open the pool from which data buffers or messages are to be allocated. The default pools shipped with DSP/BIOS™ LINK are: 1. SMAPOOL: For zero-copy buffers allocated from memory with shared access across processors. 2. BUFPOOL: For fixed-size buffers. The buffers can be allocated and freed from the pool from the ISR and DPC context.
Each pool must be initialized only once. However, multiple pools (of differing IDs) using the same pool function table can be configured using the static configuration tool. Each of these pools must be initialized once. APIs used 1. POOL_open ()
31

Importing Open-BTS Software on BeagleBoard

2011

5.2.2.2.2 EXECUTION

1. Allocate a buffer from the pool. 2. If required, translate the allocated buffer between different address spaces (user, kernel, physical, DSP). 3. Free the buffer previously allocated from the pool.
APIs used 1. POOL_alloc () 2. POOL_translateAddr () 3. POOL_free () 5.2.2.2.3 FINILIZATION 1. Close the pool Relevant APIs 1. POOL_close () 5.2.2.3 CHNL

This component represents a logical data transfer channel in the application space. CHNL is responsible for the data transfer across the GPP and DSP. CHNL is an acronym for ‘channel’. A channel (when referred in context of DSP/BIOS™ LINK) is: • A means of transferring data across GPP and DSP. • A logical entity mapped over a physical connectivity between the GPP and DSP. • Uniquely identified by a number within the range of channels for a specific physical link towards a DSP. • Unidirectional. The direction of a channel is decided at run time based on the attributes passed to the corresponding API.

32

Importing Open-BTS Software on BeagleBoard

2011

Multiple channels may be multiplexed on single physical link between the GPP and DSP depending upon the characteristics of the link & associated link driver. The data being transferred on the channel does not contain any information about the source or destination. The consumer and producer on either side of the processor boundary must establish the data path explicitly. This component follows the issue-reclaim model for data transfer. As such, it mimics the behavior of issue-reclaim model of the SIO module in DSP/BIOS™.
5.2.2.3.1 INITIALIZATION

1. Create the channel for data transfer across the GPP and DSP. 2. Allocate the buffer(s) to be used for transferring the data across the channel. 3. Prime the buffers before initiating the data transfer. The applications must decide on the channels to be used for data transfer. The channel must be opened in appropriate directions on the GPP and DSP to allow the transfer to take place.

APIs used 1. CHNL_create () 2. CHNL_allocateBuffer () 5.2.2.3.2 EXECUTION

1. Issue allocated buffer(s) to the channel(s) created earlier. Usually: • A primed buffer is issued on an output channel to be received by the remote client on the DSP. • An empty buffer is issued on an input channel to receive the data issued by remote client on the DSP. 2. Reclaim a buffer on the channel to which a buffer was issued in the previous step. This is a synchronous operation i.e. the execution of the client is blocked until the IO operation is successful (or a timeout occurs).
33

Importing Open-BTS Software on BeagleBoard

2011

Relevant APIs 1. CHNL_issue () 2. CHNL_reclaim () 5.2.2.3.3 FINILIZATION 1. Free the buffer(s) allocated on the in the initialization step. 2. Delete the channel. Relevant APIs 1. CHNL_freeBuffer () 2. CHNL_delete () 5.2.3 Getting started with writing applications

To write applications using DSP/BIOS™ LINK, it is important to select the most appropriate DSPLINK modules to be used as per the system and application design. Based on the application’s requirements, all or a subset of the features provided by DSPLINK can be used. For an example to get you started, the LOOP sample application is included in Appendix B. The following section describes simple application scenarios. This information can be used to select the modules providing the most optimum performance and footprint for the system, while still giving the simplest application design.
5.2.3.1 Generic information

1. PROC component is always required for all applications using DSP/BIOS LINK. This component provides the basic functionality to setup, boot-load, control and communicate with the processors in the system. 2. To understand how the APIs for each component are used, the GPP and DSP-side of the sample applications provided with each DSPLINK release can be used as reference. 3. In addition, a description of the setup, execution and shutdown control flow for each component is given within the User Guide found in the DOC

34

Importing Open-BTS Software on BeagleBoard

2011

directory of the DSPLINK folder after installing DSPLINK as we will see later. The designs of the sample applications are also detailed in the User Guide.
5.2.3.2 Component features

The following information may be useful to decide which DSPLINK component is best suited to meet the application’s messaging and data transfer requirements:
5.2.3.2.1 NOTIFY

NOTIFY component may be used for messaging/data transfer if: 1. Only 32-bit information needs to be sent between the processors. 2. Prioritization of notifications is required. For example, one low priority event (e.g. 30) can be used for sending buffer pointers. A higher priority event (e.g. 5) can be used to send commands. 3. The notification is to be sent infrequently. If multiple notifications for the same event are sent very quickly in succession, each attempt to send a specific event spins, waiting till the previous event has been read by the other processor. This may result in inefficiency. 4. Multiple clients need to be able to register for the same notification event. When the event notification is received, the same notification with payload is broadcast to all clients registered for that event.
5.2.3.2.2 MSGQ

MSGQ component may be used for messaging/data transfer if: 1. Application requires single reader and multiple writers. 2. More than 32-bit information needs to be sent between the processors using application-defined message structures. 3. Variable sized messages are required. 4. Reader and writer operate on the same buffer sizes. 5. Messages need to be sent frequently. In this case, the messages are queued and there is no spin-wait for the previous event to be cleared.

35

Importing Open-BTS Software on BeagleBoard

2011

6. The ability to wait when the queue is empty is desired. This is inbuilt within the MSGQ protocol, and no extra application code is required. If MSGQ_get () is called on an empty queue, it waits till a message is received. If NOTIFY is used, the application must register the callback, or wait on a semaphore that is posted by the application’s notification callback function. 7. It is desired to have the ability to move the Message Queue between processors. In this case, the MSGQ_locate () on other processors internally takes care of locating the queue, and the application code sending messages to this queue does not need to change. 8. It is desired to also have DSP-DSP communication. In this case, Message Queue component in DSP/BIOS allows usage of different Message Queue Transport modules independent of DSPLINK to communicate between DSPs. 5.2.3.2.3 MPLIST MPLIST component may be used for messaging/data transfer if: 1. Application requires multiple writers and multiple readers. 2. The application wishes to perform out-of-order processing on received packets. This is not possible with MSGQ or with NOTIFY. With MPLIST, the reader may traverse the shared list and choose any buffer within the list to be removed. 3. Making a specific buffer as high priority is desired. The sender to an MPLIST can make a specific buffer/message as high priority by pushing it to the head of the queue instead of placing it at the end of the queue. APIs are provided to traverse the list and insert element before any specified element in the queue. 4. Inbuilt notification is not required. If the application desires flexibility in when notification is to be sent/received, MPLIST module can be used. The application may use NOTIFY module to send & receive notifications as per its specific requirements. This may result in better performance and lesser number of interrupts, tuned to application’s requirements. However, the disadvantage is that additional application code needs to be written for notification, which is present inherently within MSGQ component. 5. Reader and writer operate on the same buffer sizes.
36

Importing Open-BTS Software on BeagleBoard

2011

6. More than 32-bit information needs to be sent between the processors using application-defined message structures. 7. Variable sized messages/data buffers are required. 8. Messages/data buffers need to be sent frequently. In this case, the messages are queued directly. No notification/spin-wait for notification is performed.
5.2.3.2.4 CHNL

CHNL component may be used for data transfer if: 1. Single reader and single writer are required. 2. Fixed size data buffers are required. 3. Reader and writer operate on the same buffer sizes. 4. Existing SIO drivers for other peripherals are to be used in conjunction with the DSPLINK driver for GPP-DSP communication. In such scenarios, SIO provides a standard means of communication and inter-operability. 5. Simple synchronized data streaming is required. For such requirements, CHNL module provides a simple issue-reclaim protocol. The application only needs to issue empty/full buffers on both processors, and these get exchanged when buffers are available on both processors on the same channel. If buffer is not available, inbuilt wait & notification is available when attempt is made to reclaim the buffer. 6. Multiple buffers can be easily queued for better performance.
5.2.3.2.5 RingIO

RingIO component may be used for messaging & data transfer if: 1. Single reader and single writer are required. 2. Data, as well as attributes/messages associated with data are to be sent & received. 3. Writer and reader need to execute independently of each other. The size of buffer used by writer may be different from the buffer size needed by reader. 4. The buffer sizes for acquire and release for writer & reader do not need to
37

Importing Open-BTS Software on BeagleBoard

2011

match. Writer/reader may choose to release lesser buffer size than was acquired, or may choose to acquire more data before releasing any data. 5. Applications have different notification needs. The application can minimize interrupts by choosing the most appropriate type of notification based on watermark. 6. It is desired to have the capability to cancel unused data that was acquired but not released. 7. It is desired to flush the contents of the ring buffer to clear the ring buffer of released data. For example, when ongoing media file play is stopped and new media file is to be streamed and decoded. The following sections give examples of possible application scenarios and suggest design and DSPLINK components to be used for each.
5.2.3.3 Static buffer system with minimal control communication with the DSP 5.2.3.3.1 Application requirements:

1. Boot-load the DSP. 2. Statically reserve a region of memory to be shared with DSP. The complete system is static. 3. GPP and DSP may need to infrequently ping each other with some control Information.

38

Importing Open-BTS Software on BeagleBoard
Suggested design:

2011

Fig. 5-3, App scenario: Static buffer system with minimal control communication with the DSP.

1. PROC module is used to boot-load the DSP. The DSP executable is present in the GPP file system. 2. Two regions of memory can be statically reserved (at compile time) through the DSPLINK dynamic configuration file (CFG_<PLATFORM>.c). On DSP-side, a similar configuration needs to be done within TCF file to reserve the memory. One region of memory can be used for GPP->DSP transfers, and the other for DSP->GPP transfers. Since the memory is statically reserved, both GPP and DSP are aware of their start addresses and sizes. 3. NOTIFY module can be used to send 32-bit control messages between the GPP and DSP.
5.2.3.3.2 DSP/BIOS LINK components used

1. PROC. 2. NOTIFY.
39

Importing Open-BTS Software on BeagleBoard

2011

5.2.3.4 Dynamic buffer system with minimal control communication with the DSP 5.2.3.4.1 Application requirements:

1. Boot-load the DSP. 2. Be able to dynamically allocate and free regions of memory to be shared with DSP. For example, this may be needed if same DSP executable is to be used with different GPP applications having different buffer size requirements. 3. Buffer requirements for each application are limited. For example, each application just needs to allocate one or two buffers during setup phase, and after this, the same buffers are used directly by GPP and DSP. 4. GPP and DSP may need to infrequently ping each other with some control information.
Suggested design:

Fig. 5-4, App scenario: Dynamic buffer system with minimal control communication with the DSP

40

Importing Open-BTS Software on BeagleBoard

2011

1. PROC module is used to boot-load the DSP. The DSP executable is present in the GPP file system. 2. A POOL is opened with a configuration of the sizes of buffers to be shared between the GPP and DSP. 3. Buffers are allocated from the POOL as required by the GPP or DSP during setup phase of the application. 4. If allocated on GPP, the buffer address received from POOL_alloc can be translated to DSP address space to get the corresponding DSP address of the same buffer using POOL_translateAddr. 5. NOTIFY module can be used to send the 32-bit buffer addresses (or other 32-bit control information) between the GPP and DSP. 6. If the buffer is allocated on DSP-side, the DSP address received on the GPP can be translated using POOL_translateAddr. 7. The buffers are now used by GPP and DSP for sending/receiving data. NOTIFY module can be used to inform the processors when data is available/freed in the buffers. 8. If both GPP and DSP may have to simultaneously access the pool buffers, and mutually exclusive access is to be provided to the buffers, the MPCS module can be optionally used to protect access to the buffers.
5.2.3.4.2 DSP/BIOS LINK components used:

1. PROC. 2. NOTIFY. 3. POOL. 4. MPCS (optional).
5.2.3.5 Multiple buffers to be sent between GPP and DSP 5.2.3.5.1 Application requirements:

1. Boot-load the DSP 2. Be able to dynamically allocate and free regions of memory to be shared with DSP. 3. Multiple buffers are required by each application. The buffers may be allocated and freed at run-time. The buffers need to be sent between GPP and DSP during execution phase.
41

Importing Open-BTS Software on BeagleBoard
Suggested design:

2011

Fig. 5-5, App scenario: Multiple buffers to be sent between GPP and DSP

1. PROC module is used to boot-load the DSP. The DSP executable is present in the GPP file system. 2. A POOL is opened with a configuration of the sizes of buffers to be shared between the GPP and DSP. 3. Buffers are allocated from the POOL as required by the GPP or DSP. 4. If allocated on GPP, the buffer addresses received from POOL_alloc can be translated to DSP address space to get the corresponding DSP addresses of the same buffers using POOL_translateAddr. 5. If the buffers are to be sent infrequently, the NOTIFY module can be used to send the 32-bit buffer addresses (or other 32-bit control information) between the GPP and DSP. If one processor may need to send multiple buffers to the other processor in one shot, either MSGQ or MPLIST module can be used. If additional information (e.g. buffer attributes) is required to be associated with the data buffer, a message structure can be defined that has these attributes, and MSGQ or MPLIST component can be used to send the message to the other processor. 6. If the buffers are allocated on DSP-side, the DSP addresses received on the GPP can be translated using POOL_translateAddr.
42

Importing Open-BTS Software on BeagleBoard
5.2.3.5.2 DSP/BIOS LINK components used:

2011

1. PROC. 2. NOTIFY / MSGQ / MPLIST. 3. POOL.
5.2.4 Support for multiple DSP boot modes Overview

Multiple applications/processes on the GPP may wish to use the services provided by DSPLink to control and communicate with the DSP. DSPLink supports multiple boot modes to enable different use cases. DSPLink PROC module supports three different scenarios for DSP boot-loading: • Normal Boot Mode: DSPLink loads and starts the DSP running. o DSP_BootMode_Boot_NoPwr. o DSP_BootMode_Boot_PwrDefault. • External Load Mode: DSPLink only starts the DSP running. o DSP_BootMode_NoLoad_NoPwr. o DSP_BootMode_NoLoad_Pwr.
• External Load and Start Mode: DSPLink does not load or start the DSP running. o DSP_BootMode_NoBoot.

In all modes, the application calls all DSPLink APIs for PROC module. DSPLink internally checks the boot mode and accordingly determines the correct action to be taken for each API. For example, APIs PROC_load, PROC_start, PROC_stop need to be called even in External Load or External Load and Start mode.
5.2.4.1 Normal Boot Mode In this boot mode: • GPP boots first • Uses DSPLink to load the DSP • Uses DSPLink to start the DSP running
43

Importing Open-BTS Software on BeagleBoard

2011

Fig. 5-6, Normal Boot Mode

5.2.4.1.1 DSP_BootMode_Boot_NoPwr

In this boot mode, DSPLink does not do power management of DSP. • PROC_attach places the DSP in local reset. It does not power up the DSP. • PROC_load loads the DSP executable into DSP memory. • PROC_start sets entry point for DSP i.e. c_int00 and release DSP from reset. • PROC_stop places DSP in local reset. • PROC_detach does not power down the DSP
5.2.4.1.2 DSP_BootMode_Boot_Pwr

In this boot mode, DSPLink does power management of DSP. • PROC_attach places the DSP in local reset. It powers up the DSP. • PROC_load loads the DSP executable into DSP memory. • PROC_start sets entry point for DSP i.e. c_int00 and release DSP from reset. • PROC_stop places DSP in local reset. • PROC_detach powers down the DSP.

44

Importing Open-BTS Software on BeagleBoard
5.2.4.2 External Load Mode

2011

In this boot mode: • GPP boots first. • Application/GPP boot-loader pre-loads the DSP. • Uses DSPLink to optionally power up the DSP. • Uses DSPLink to start the DSP running.

Fig. 5-7 External Load Mode

5.2.4.2.1 DSP_BootMode_NoLoad_NoPwr

• • • • •

PROC_attach places the DSP in local reset. It does not power up the DSP. PROC_load does not load the DSP executable into DSP memory. PROC_start sets entry point for DSP i.e. c_int00 and release DSP from reset. PROC_stop places DSP in local reset. PROC_detach does not power down the DSP.

5.2.4.2.2 DSP_BootMode_NoLoad_Pwr

• • • •

PROC_attach places the DSP in local reset. It powers up the DSP. PROC_load does not load the DSP executable into DSP memory. PROC_start sets entry point for DSP i.e. c_int00 and release DSP from reset. PROC_stop places DSP in local reset.
45

Importing Open-BTS Software on BeagleBoard
• PROC_detach powers down the DSP.
5.2.4.3 External Load and Start Mode

2011

There are two scenarios to be supported for this boot mode: • GPP-based load 1. GPP boots first 2. Application/GPP boot-loader pre-loads the DSP 3. Application/GPP boot-loader starts the DSP running 4. Uses DSPLink only for IPC with the DSP OR • DSP-based load 5. DSP boots first, starts running an application 6. ARM comes up later and sets up DSPLink, which initializes shared memory 7. DSPLink is not used to load or start the DSP 8. Uses DSPLink only for IPC with the DSP

Fig. 5-8, External Load And Start Mode

46

Importing Open-BTS Software on BeagleBoard
Only NoPwr based mode is supported when NoBoot mode is selected.
5.2.4.3.1 DSP_BootMode_NoBoot

2011

• PROC_attach does not place the DSP in local reset. It does not power up the DSP PROC_load does not load the DSP executable into DSP memory. • PROC_start does not set entry point for DSP i.e. c_int00 and does not release DSP from reset. • PROC_stop does not place DSP in local reset. • PROC_detach does not power down the DSP. Hint: Application changes to support each Mode can be found in Texas Instrument's DSP/BIOS LINK Programmers Guide.
5.2.5 Installation of DSPLINK

Steps for installing DSPLINK on host environment can be found in Appendix B
5.3 Other GPP/DSP Communication Tools

In terms of GPP and DSP communication, there is another mechanism provided by TI called the Codec Engine, as shown in Fig. (5-9). Using this method, a GPP application would utilize a Digital Video Software Development Kit (DVSDK) which integrates Codec Engine with other components needed to support DSP/GPP integration. The Codec Engine represents the core component of the DVSDK. There are two components of the Codec Engine, an engine component representing the GPP side of the system and a server component representing the DSP side of the system. The framework component is used to initialize and allocate resources associated with a DSP codec. The application developer is able to run various DSP based functions which adhere to TI specified standard interfaces such as eXpress DSP Algorithm Interoperability Standard (XDAIS). DSP codecs are able to allocate DSP resources by using the framework component.

47

Importing Open-BTS Software on BeagleBoard

2011

Both GPP/DSP communication mechanisms allow the realization of SDR applications utilizing the DSP; however, the DSPLink interface is used because it is simpler and provides a more direct connection between the GPP and DSP cores. The Codec Engine approach can be more beneficial in a scenario where developers purchase commercial DSP implementation of signal processing algorithms where vendors would not make their source code available. In that scenario an application developer is able to utilize the Codec Engine to invoke the algorithms unlike with the DSPLink approach it is necessary to have the source code of the algorithms being invoked.

Figure 5-9, Codec Engine GPP/DSP Programming Approach

TI also provides tools which are installed and used on top of the DSPLink and Codec Engine to further enhance the user experience, for example: C6Flo, C6EZRun, and C6Accel. C6Flo is a graphical tool intended to configure the DSP graphically by loading drivers, configuring DSP peripherals, and connecting DSP blocks, or functions. The GUI tool ultimately generates C-code which is then fed to the DSP compiler. The motivation here is to make programming the DSP easier by using a GUI rather than manually setting it up by writing C-code. C6EZRun is intended to generate code for the DSP using portable C-code with the motivation to enable developers not familiar with DSP programming to generate and run DSP programs with C6EZRun taking care of compiling the code and setting up the DSP. C6Accel allows developers to call functions which are part of the TI signal processing libraries using the Codec engine interface. Again, the user does not

48

Importing Open-BTS Software on BeagleBoard

2011

need to worry about the specifics of setting up the DSP or how to use the Codec engine APIs. In the next section we will focus on C6EZRun. We will go through an overview of C6EZRun, installing it on host environment, running it on target platform and writing our own application using C6EZRun Makefiles.

5.3.1 C6EZRUN

The aim of C6EZRun is to ease initial development and loading of DSP code for ARM developers who are familiar with building applications for the Linux OS using an ARM GCC cross-compiler. This project should be of particular interest to ARM developers who are familiar with the command-line ARM GCC crosscompiler and who want a similar mechanism to build and run code on the DSP. It can be helpful in developing applications that would run on BeagleBoard with no need to be aware of all the details of DSP/BIOS link modules.

5.3.1.1 What is C6EZRun?

C6EZRun is a free, open-source development tool from Texas Instruments that allows the user to seamlessly use the DSP on heterogeneous ARM+DSP devices. It is intended to ease development of DSP code on two-core heterogeneous SoC processors from Texas Instruments, specifically targeting ARM+DSP devices. This project is used in systems running ARM Linux and containing a C6000 DSP core. C6EZRun supports OMAP3530/25 with ArmCortex-A8 and TMS320C64x+ fixedpoint DSP core which are integrated on the BeagleBoard among other platforms.

49

Importing Open-BTS Software on BeagleBoard
5.3.1.2 What does C6EZRun actually do?

2011

The C6EZRun project allows you to seamlessly use the DSP from the ARM core on TI's ARM+DSP devices, without having to deal with any advanced, and potentially complicated, frameworks and software stacks. C6EZRun is a set of tools which will take in C files and generate either an ARM executable, or an ARM library which will leverage the DSP to execute the C code.
5.3.1.3 What does C6EZRun Consist Of?

The project consists of two main components: 1. A build system to create back-end libraries composed of various TI software technologies and the code of the C6EZRun framework itself. 2. Front-end scripts that wrap the TI C6000 code generation tools in a GCClike interface. These scripts make use of the back-end libraries and build system to create ARM-side components that transparently make use of the DSP. There are two uses of the C6EZRun project, exposed through two different frontend scripts. They are called C6RunLib and C6RunApp.
5.3.1.3.1 C6Runlib

C6RunLib works to build a static ARM library from C source files that can be linked with an ARM application and provide access to the DSP when library functions are called. This allows the user to keep portions of the application on the ARM and move other portions to the DSP. C6Runlib script is shown in Fig. (5-10) The C6RunLib front-end consists of two scripts, c6runlib-cc and c6runlib-ar. The c6runlib-cc tool is used to compile C code to C6000 DSP object files. The c6runlib-ar tool is a specialized archiver that takes the DSP object files produced
50

Importing Open-BTS Software on BeagleBoard

2011

by the c6runlib-cc tool and generates an ARM side library. This output library can then be linked to the ARM application to provide mostly transparent access to the DSP via the unchanged library interfaces. The application can be run from the ARM/Linux command-line as a native ARM application. Underneath the covers, however, the DSP is initiated, loaded with program code (which consists of the library functions), and runs waiting for function calls to arrive from the ARM application. All C I/O operations (printf, scanf, fopen, etc.) are routed to the ARM environment and console.

Fig. 5-10, C6Runlib

5.3.1.3.1.1 C6Runlib front-end tool usage:

C6Runlib-cc The c6runlib-cc tool is a Bash shell script, intended to be run on a host Linux PC. The tool is used to compile C code and generate a C6000 object file. It does this by calling the TI C6000 compiler tool with appropriate command-line options. The command-line syntax of the c6runlib-cc tool matches the syntax used by the open source GCC compiler.

51

Importing Open-BTS Software on BeagleBoard

2011

The c6runlib-cc tool currently only supports C source files. The source files compiled and assembled by c6runlib-cc are analyzed and used to produce two additional source files. These are remote-procedure call stubs, one for the ARM side and one for the DSP side. These files are also compiled to object file format by the c6runlib-cc script and are output to the same output directory specified for the main output object file. These object files are the same name as the specified output object file but with ".gpp_stub.o" and ".dsp_stub.o" extensions, respectively. The c6runlib-cc tool does not support linking (as opposed to the GCC compiler). The outputs of the c6runlib-cc tool are intended to be fed to the c6runlib-ar archiver tool. C6Runlib-ar The c6runlib-ar tool is also a Bash shell script, intended to be run on a host Linux PC. It is used to create an ARM/Linux static library that can be linked into an application. To do this, the script calls the TI cl6x compiler/linker, the ARM GCC compiler, and the ARM GNU archiver as needed. The c6runlib-ar tool relies on all the files output from the c6runlib-cc tool to be in the same path in the filesystem, which is how they are generated by the c6runlib-cc tool. The archiver tool then uses the cl6x tool to link and build the DSP executable image, including all the object files given on the command-line and the corresponding DSP-side stub objects. The DSP executable is analyzed and the symbol addresses for the library functions are extracted and used to generate object files with absolute symbol references for the ARM-side application. The ARM side remote procedure call stub functions compiled by the c6runlib-cc tool rely on these absolute symbol references to get the function addresses at link time of the ARM application. Next the c6runlib-ar tool will convert the DSP executable image into a constant array in a C header file which is included in the main c6runlib task function. That task function is compiled using the ARM cross-compiler to generate an object file. Finally, the c6runlib-ar tool will generate a library archive consisting of the ARM-side remote procedure call stubs, the function address symbols, the various backend components (DSPLink, CMEM) and the C6RunLib task function.

52

Importing Open-BTS Software on BeagleBoard

2011

CMEM is a contiguous memory manager. The C6EZRun framework allocates the entire CMEM region at once when the first buffer is requested from the framework. This physically contiguous heap memory is then managed in user space on the ARM side, avoiding costly user- to kernel-space transitions for every buffer allocation. So each application written in C should be managed by CMEM and choosing the proper memory buffer sizes which is needed to run the excutable(Arm or Dsp) on beagleboard.

5.3.1.3.2

C6Runapp

It's simplest form, this tool acts as a cross-compiler for the DSP, allowing portable C applications to be rebuilt for the C6000 DSP core of various Texas Instruments heterogeneous (ARM+DSP) processors. The C6RunApp front-end consists of a single script, called c6runapp-cc. This use of this script matches, as much as possible, the use of GCC. It can compile C code to C6000 object files and link the C6000 object files into an application. When performing linking operations, the tool makes use of a number of steps (including linking using the C6000 code generation tools) to create an ARM-side executable from the DSP object files. Once built, the application can be run from the ARM/Linux command-line as if it were a native ARM application. Underneath the covers, however, the DSP is initiated, loaded with the program code, and runs the application to completion. All C I/O operations (printf, scanf, fopen, etc.) are routed to the ARM environment and console. This makes the application appear as another ARM process, but all of the C code compiled using this tool runs on the DSP core of the SoC. C6Runapp framework is shown in Fig. (5-11)
5.3.1.3.2.1 C6Runapp front-end tool usage

For C6Runapp front-end tool usage it's the same as C6Runlib.

53

Importing Open-BTS Software on BeagleBoard

2011

Fig. 5-11, C6Runapp

5.3.1.4

How to compile an example (building code on host computer)

5.3.1.4.1 In case of using C6Runlib

Compile a single C source file to an library file:

[host]$ c6runlib-cc -c -o libfxns.o libfxns.c

The output of the c6runlib-cc call is three files: 1. the DSP object file, libfxns.o. 2. the ARM stub object file, libfxns.arm_stub.o. 3. and the function name list, libfxns.fxn_list.txt. Archive a single object file into a library file:
54

Importing Open-BTS Software on BeagleBoard

2011

[host]$ c6runlib-ar rcs libfxns.lib libfxns.o

The output of the c6runlib-ar call is a library archive called libfxns.lib.

Generating a complete ARM executable using a C6RunLib library file:

[host]$ arm-none-linux-gnueabi-gcc -c -o main.o main.c

[host]$ arm-none-linux-gnueabi-gcc -lpthread -o program.out main.o libfxns.lib

The output is an ARM executable, program.out. Any function calls made in main.c to functions defined in libfxns.c will be executed by the DSP of the target platform.
5.3.1.4.2 In case of using C6Runapp

Compile a single C source file to an object file:

[host]$ c6runapp-cc -c hello_world.c

The output is a file called hello_world.o.
55

Importing Open-BTS Software on BeagleBoard

2011

Compile a single C source file to an executable of default name:

[host]$ c6runapp-cc hello_world.c

The output is a file called a.out.

Compile a single C source file to an executable of specified name:

[host]$ c6runapp-cc -o hello_world.out hello_world.c

The output is a file called hello_world.out.

Compile a multiple C source files to object files:

[host]$ c6runapp-cc -c bench.c distance.c

The output is two files, called bench.o and distance.o.

Compile multiple C source files to an executable of default name:

56

Importing Open-BTS Software on BeagleBoard
[host]$ c6runapp-cc bench.c distance.c

2011

The output is a file called a.out.

Compile multiple C source files to an executable of specified name:

[host]$ c6runapp-cc -o test.out bench.c distance.c

The output is a file called test.out.

Compile multiple C source files to an executable using optimization level 3:

[host]$ c6runapp-cc -O3 -o test.out bench.c distance.c

The output is a file called test.out.

5.3.1.5

Installation of C6EZRUN

Steps for installing C6EZRUN on host environment and getting C6EZRun applications to run on target platform can be found in Appendix B

57

Importing Open-BTS Software on BeagleBoard Chapter 6: Executing GNU Radio Blocks on DSP

2011

Note: Most content of this chapter is copied from Designing a Software Defined Radio to Run on a Heterogeneous Processor thesis written by Dr. Almohanad S. Fayez, which can be found here: http://scholar.lib.vt.edu/theses/available/etd-05042011190721/unrestricted/Fayez_AS_T_2011_1.pdf

In order to make the DSP in the OMAP3530 processor readily available for SDR applications, we were supposed to integrate the DSP into the GNU Radio framework. The basic idea is to add new functional blocks to GNU Radio which are DSP-based so GNU Radio applications utilizing TI OMAP processors are able to make use of the on board C64x+ DSP by electing to use the DSP functions instead of the ARM GPP based ones. As discussed before there are many different software frameworks and toolkits involved in using and setting up an embedded platform, communication between multi-core processors, GPP, and for creating SDR applications.
6.1 Components to Set Up GPP/DSP SDR Based Applications

Three main components are required to allow GPP/DSP based SDR applications to run on the Beagleboard: a) GPP Side Library: The GPP side library is responsible for abstracting the DSPLink function calls. For example, it would provide a function call to initialize the DSP without exposing the initialization details to the user. This library also provides function calls which allow data and messages to be exchanged between the GPP and DSP without exposing the details of the interface. b) DSP Side Executable: The executable is a DSP program which can receive requests from the GPP to execute particular signal processing functions and is able to handle receive a stream of data for processing and send the processed data back to the GPP. c) GNU Radio DSP-Based Blocks: To allow DSP-based blocks to be integrated with GNU Radio, new GNU Radio blocks are developed which through the
58

Importing Open-BTS Software on BeagleBoard

2011

discussed GPP side library are able to transmit requests for particular signal processing functions, send data streams to the DSP for processing, and receive the processed data from the DSP.
6.1.1 GPP side library The GPP library currently uses three components from DSPLink: a) PROC: the processor component. b) POOL: the shared memory con_guration and management component. c) CHNL: the channel component.

The PROC component is used to initialize the DSP processor, load DSP executables, and stop DSP execution; basically it allows users to setup and load the DSP. The POOL component configures and synchronizes the shared memory regions between the GPP and DSP necessary for inner-processor data transfers. The CHNL component instantiates a logical data transfer link, or channel, between the GPP and DSP. While the CHNL component manages the logical data link between the DSP and GPP, the POOL component manages the physical memory used for the CHNL component including all the necessary memory allocation, synchronization, and address translation between the GPP and DSP. The GPP library essentially abstracts the DSPLink function calls necessary to initialize the DSP, instantiate the shared memory region, create the channel constructs, and the physical exchange of data back and forth with the DSP. The GPP library abstracting the DSPLink interface performs five main functions: a) Initialize DSP: Initialize the DSP. b) Transmit Data (Complex): Send complex IQ data to the DSP. c) Receive Data (Complex): Receive complex IQ data from the DSP. d) Transmit Data (Real): Transmit real data to the DSP. e) Receive Data (Real): Receive real data from the DSP. f) Clear DSP: Called when the user application does not need the DSP anymore. It deal-locates DSP specifc resources and buffers that were allocated by the DSP initialization functions.

59

Importing Open-BTS Software on BeagleBoard

2011

It is necessary to support functions for moving complex IQ and real data because radio transmitters and receivers can have a complex IQ and/or real data paths. When developers use any of the above functions they need to specify a pointer to the transmit or receive buffers, buffer size, interpolation factor, decimation factor, a scaling factor, and a block ID tag. The scaling factor is used to identify the fixed point representation, or Q-Format. Since the DSP is fixed point, data needs to be converted from floating point to fixed point format before transmitting it to the DSP. The GPP library takes care of the data type conversion by taking the scaling factor and multiplying values by 2scale before sending the data to the DSP, and it also converts received data from the DSP back to floating point format by dividing by 2scale. The GPP/DSP interface is able to handle transmitting/receiving 8192 16-bit real data points or 4096 16-bit complex data points at a time because of a DSPLink buffer size restriction. Therefore in case buffers sizes exceed the limit they are fragmented. DSPLink allows programs to be either Task (TSK) based or Software Interrupt (SWI) based. TSK based programs are synchronous, meaning that processors will make blocking function calls to each other. When the GPP wants to communicate data to DSP, it will block, or wait, until the DSP is ready. Also when the DSP wants to send data to the GPP it will block until the GPP is ready to receive the data from the DSP. When a processor is in the middle of a blocking transmit or receive function, it is wasting time that can be used to compute instead of waiting. In the SWI mode, the GPP transmit function actually causes a software interrupt in the DSP. The interrupt allows the DSP to receive data without the GPP having to block. When the DSP wants to transmit data to the GPP it causes a software interrupt on the GPP and the GPP receives the data without having the DSP block. While the current design is TSK-based, part of the future work is to make it SWIbased. DSPLink based-programs can be compiled as executables or static libraries. A static library is a compiled object, and when a program links to it, a program's linker would extract the code for the associated library and physically place the
60

Importing Open-BTS Software on BeagleBoard

2011

pieces of code in the program. In this case, the interest is to create a library and have DSP function calls made by SDR application developers go through the GPP library. By doing this, applications do not have to be aware of specific aspects associated with the shared memory interface nor the DSP. In case the static library implementation changes at any point all programs using the library need to be recompiled so they can update the extracted code from the static library. Originally the GPP library was static since this is the only library format available through the DSPLink toolkit; however, it proved to be problematic when starting using the GPP library in GNU Radio functions. GNU Radio functions, or blocks, are called in Python, so the GPP function calls are wrapped with SWIG wrappers which allow the function calls to be carried between different programming languages. However, the issue with static libraries is that different modules can end up with different copies of the same static library which can cause issues since there is only one DSP and a single interface to that DSP. Basically, the user might initialize the DSP by calling the associated function but when a DSP block is called to implement a Finite Impulse Response (FIR) filter, the DSP FIR call might fail because the GPP library thinks that the DSP is uninitialized. The previous issue can occur if the DSP initialization Python function has a different copy of the GPP library than the DSP FIR Python function. Ultimately it was necessary to generate a shared, GPP library. Unlike static libraries, shared libraries allow programs to establish dynamic links to them during runtime. When a library is updated the calling program does not need to be recompiled because function calls are dynamically linked. Since DSPLink does not support generating shared libraries, we used the frame work of Dr. Almohanad to generate a shared library using OE. The object file generated by the compiler, gpplib.o, is copied and then an OE recipe is written which takes the assembler object file and generates a shared library. By using a shared library, all GNU Radio DSP calls have access to one singular instance of the library, which is the desired behavior. The OE recipe ultimately generates packages and the packages are installed on the Beagleboard manually.

61

Importing Open-BTS Software on BeagleBoard

2011

6.1.2 DSP-Side Executable

The DSP image is an executable and currently has functionalities for complex and real FIR filtering and FM modulation and demodulation. The DSP image is loaded via the GPP side library using the PROC component from DSPLink. The DSP-side program depends on two TI libraries: C64x+ DSP Library and the C64x+ IQMath library. The DSP Library is an open source library with functions such as FIR filters, Infinite Impulse Response (IIR) filters, and FFT. The functions are written specifically to make use of the C64x+ DSP architecture. This library was used for implementing complex and real FIR filtering. The IQMath library is a virtual floating point library; the main reason for using this library is to be able to implement trigonometric functions associated with FM modulation and demodulation. This library can be found on Texas Instruments website. Applications running on the GPP are able to send requests to set up DSP processing blocks and the DSP will set them up accordingly. The GPP/DSP messages are formatted as shown in fig.(6-1).
Block Type Block ID Scaling Factor Interp. Factor Decim. Factor Payload Payload Size

Fig. 6-1, GPP/DSP message format

a) Block Type: Determines the block request type. o CCF INIT: Set up a complex FIR filter with real coefficients. o CCF FM DEMOD INIT: Set up a complex FIR filter followed by FM demodulation. o CCF FM DEMOD DECIM INIT: Set up a complex FIR filter followed by FM demodulation and decimation. o CCF FM MOD INIT: Set up an FM modulation block followed by a complex FIR filter.

62

Importing Open-BTS Software on BeagleBoard

2011

o DSP PROCESS: This is a stream of data from the GPP intended to be processed by the DSP. The DSP will look at the Block ID included in the message to decipher how it should process it. The DSP would have stored information about processing the data when the associated INIT block type was originally passed by the application.

b) Block ID: The GPP passes a distinct ID with all of the message streams it sends to the DSP. The block ID is used in storing all the relevant block information. c) Scaling Factor: Passes the scaling factor used in the fixed to floating data type conversion. d) Interp. Factor: The interpolation factor requested from the DSP. e) Decim. Factor: The requested decimation factor from the DSP. f) Payload Size: When an INIT message is passed, the payload size refers to the number of FIR taps being passed in the message. When a DSP PROCESS message is passed, the payload size refers to the number of data elements in the current data stream. g) Payload: When an INIT message is passed, the payload is the FIR Filter coefficients. When a DSP PROCESS message is passed, the payload is the data in need of processing.

6.1.3 GNU Radio DSP-Based Blocks

GNU Radio blocks are written in C++ but can be called using either C++ or Python. They can be called in C++ by linking directly to the GPP library and they can be invoked in Python via SWIG wrappers. By using Python, an interpreted non-compiled language, it is not necessary for programmers to recompile their GNU Radio flow Graphs whenever they modify them. This allows rapid prototyping without the overhead of cross compilation. Fig. (6-2) illustrates the
63

Importing Open-BTS Software on BeagleBoard

2011

interaction between the GPP, DSP, the libraries, and various programming languages used. The DSP block in the figure would include either a single function or a chain of functions.

GNU Radio Python Invoke DSP Setup Flow Graph

SWIG

GNU Radio C++ Invoke library calls

Library Functions Calls
DSP program FIR filtering GPP library

DSPlink

Init DSP Load DSP program Transmit Data Receive Data

Fig.6-2, The programming flow between GNU Radio, GPP library and DSP Executable

From a GNU Radio perspective, DSP based blocks are encapsulated and abstracted to a degree where GNU Radio cannot distinguish between them and their GPP counterparts, although the programmer needs to distinguish whether a GPP or DSP block should be used. fig. (6-3) demonstrates the abstraction.
Python

SWIG C++
GNU Radio Block DSP Link
DSP

DSP Link 64

GNU Radio Block

Importing Open-BTS Software on BeagleBoard

2011

Fig. 6-3, DSP Based GNU Radio Block Abstraction

The GNU Radio DSP blocks implement the block types discussed in the DSP section and they are named as follows: o dsp ccf: Implements a complex FIR filter with real coefficients. o dsp ccf fm demod: Implement a complex FIR filter followed by FM demodulation. o dsp ccf fm demod decim: Set up a complex FIR filter followed by FM demodulation and decimation. o dsp ccf fm mod: Set up an FM modulation block followed by a complex FIR filter. o dsp init: Initializes the DSP. o dsp clean: Deallocates DSP related resources. As an application of what we have discussed is the loopAl2 sample done by Dr. Almohanad AlFayez which can be downloaded from this website: https://github.com/alfayez/gr-dsp/
6.2 Compilation and Execution of LoopAl2 Sample 6.2.1 a) b) c) d) Assumptions Knowing what OE is. Using Angstrom 2010 as your OS. Using OE to build a base filesystem for a BeagleBoard and/or USRP E100. DSPLINK is already installed.

6.2.2 What’s Included 6.2.2.1 DSPLINK_Code

6.2.2.1.1 DSP

65

Importing Open-BTS Software on BeagleBoard

2011

This section is about the DSP-side source code. It Includes a dependency to the IQ_MATH_c64x+ TI library. o “cpExe.sh” script is used to compile and copy the executable, loopAl2.out, to a known location. o “loopAl2” folder should be copied over into the DSPLink DSP examples folder. o The generated excutable “loopAl2.out” must be in the same folder as the flowgraph you will be invoking the DSP from. For now the executable name is hard coded.
6.2.2.1.2 GPP

This section Includes source code necessary for building the DSPLink GPP library. o The *.o should be taken from the DSPLINK folders and used with OE to cross compile the shared library. o The buildLib.sh script is used to compile and copy the necessary files to their directory so OE can be used to build the GPP library. o The “loopAl2” folder should be copied into the DSPLink GPP examples folder.
6.2.2.2 Sample_makefiles

When DSPLINK is installed, the system makefiles need to be modified to point to all the right tools and directories.
6.2.2.3 InitBeagle.sh

An initialization script has to load various TI drivers. They should be loaded at startup instead of loading them this way. cmemk and sdmak drivers are not needed for gr-dsp to work.
6.2.2.4 OE_recipes:

• Gpp_lib
66

Importing Open-BTS Software on BeagleBoard

2011

o This folder includes the necessary recipe to build the install packages for the GPP. o The “Files” folder has a header file and the *.o needed to build the library. The “buildLib.sh” script should move the files here from the GPP DSPLink directory. • Gr-dsp o This folder includes a recipe to build the GNU Radio blocks which utilize the DSP. o Also includes a tar with the source files. o All of what is here is placed in the GNU Radio recipe folder in the OE but you can make a separate folder if you would like. o You can run “bitbake –b recipe”. 6.2.2.5 Omap_sample_flowgraphs

Sample flowgraphs which use DSP based blocks are not really the best looking flowgraphs. IMPORTANT: make sure that you have the DSP executable “loopAl2.out” in the same folder as your flowgraph or you won’t be able to load the DSP.
6.2.2.6 Pre-baked-packages-2_6_37

This folder contains packages you can install to use the GNU Radio DSP extensions. You can use them to avoid dealing with any OE related pain.
6.2.3 Building OE Recipes • The GPP-lib recipe should be built before the gr-dsp recipe. • Installing packages on the Beagleboard or E100: o Opkg install “package name”
67

Importing Open-BTS Software on BeagleBoard

2011

o Opkg install --force-reinstall “package name”; Force the reinstall of a package without opkg complaining that the package already exists.

There’s a bug where when I reinstall a package after modifying it opkg occasionally complains about the package trying to re-write an existing file. When that happens just run the command again after it fails and it should work.
6.2.4 List of Blocks • Dsp.init(): initializes the DSP. • Dsp.clean(): De-allocates DSPLink related resource. • Dsp.fir_ccf(coeff, scaling, interpolation, input sig, output sig, init DSP, block_id) o Coefficients: normalized coefficients, for now the filter tap size is restricted to 490. o scaling factor = [0, 15]. o input signature: 0: normalized, input needs to be scaled before being sent to the DSP … the DSP is fixed point. 1: input is already scaled properly by a factor equal "scale", just pass it to the DSP. o output signature: 0: normalize output. 1: keep output in the same scale factor as it was on the DSP. o Initialize DSP: (set to 0 use dsp.init() instead): 0 = no, will init using dsp.init(). 1 = yes, please init o Block_id must pick either 0 or 1 for block id. Will be more agile sometime in the future. There's support for only two blocks for now. o Dsp.fir_ccf_fm_demod(coeff, scaling, interpolation, input sig, output sig, init DSP, block_id)
68

Importing Open-BTS Software on BeagleBoard

2011

Implements a ccf filter followed by FM demod before sending the data back to the DSP o Dsp.fir_ccf_fm_demod_decim(coeff, scaling, decimation, input sig, output sig, init DSP, block_id) Implements a ccf filter followed by FM demod and decimates the buffer before sending the data back to the DSP. It assumes that user will filter the result with an FFF filter on the GPP to finish performing the filter … will change as soon where it’s all done on the DSP o Dsp.fir_fff Don't use it … at least not now something needs to be fixed.

69

Importing Open-BTS Software on BeagleBoard

2011

Analysis
From the previous discussion, running applications on Heterogeneous processors can be done using static or shared libraries. Static libraries are used in DSPLINK by default, and when using C6run a static ARM library is built from C source files that can be linked with an ARM application without the need to dive into details of DSP programming. But for importing GNU Radio blocks on DSP, the issue with using static libraries is that different modules can end up with different copies of the same static library which can cause issues since there is only one DSP and a single interface to that DSP, so we have to use the shared library method. In order to use Shared libraries we have to generate them using OE through bitbaking a recipe that is used to generate a package that imports a shared library to Beagleboard as explained in chapter 6.

70

Importing Open-BTS Software on BeagleBoard

2011

Conclusion
From the previous analysis we can conclude that in order to run GnuRadio on a heterogeneous processor like the one on BeagleBoard platform we have to use the shared library method. In doing so, the developer would have to build three things: a shared GPP side library using OE which manages the DSP interface for running applications, a DSP executable which can handle functionality requests from the GPP and perform the needed signal processing on data streams, and GNU Radio DSP-based blocks to make effective use of the DSP in a SDR application setting. While the developer can use Dr. Almohanad's LoopAl2 sample as a frame work instead of starting from scratch, a good understanding of GNU Radio, OE, DSPLINK and its dependencies, which were discussed in details in this document, is required in order to use the framework and to add other GNU Radio functions that are required by an Open-BTS application.

71

Importing Open-BTS Software on BeagleBoard

2011

Recommendation For Future Work
1- For future upgrade to the SDR project, we can use Ettus Research USRP E100 software radio, Which is an embedded stand alone system powered by the combination of a TI OMAP™3 processor and a Xilinx® Spartan® 3ADSP FPGA, eliminating the need for a separate host computer (BeagleBoard) with the same cost of the USRP2 used in most Open-BTS implementations. 2- Porting Open-BTS application onto DSP 3- You could test the performance of the NEON VS DSP! Neon is a SIMD (Single Instruction Multiple Data) accelerator processor integrated in with the ARM Cortex-A8 part of the OMAP3530 on the Beagle-Board. Were during one instruction we can have many operations occurring at the same time. Since there is parallelism inside the NEON, we can get more MIPS or FLOPS out of NEON than we can get out of standard SISD processor such as the ARM running at the same clock rate. It has been proven that for certain instructions the NEON can out run the DSP only in cases where the DSP is called from the ARM using DSPLINK 4- Implementing other GNURadio functions using Dr. Almohanad's LoopAl2 sample, Also implementing it on other DSPLINK samples such as Message sample. 5- You could use one of the tools provided by Texas Instruments to facilitate the use of the DSP from the ARM, one example of these tools is C6EZRUN which was described in details in chapter 5, but you will have to find out how to add support to GNURadio.

72

Importing Open-BTS Software on BeagleBoard

2011

References

[1] http://openbts.sourceforge.net/ [2] http://www.openembedded.org/index.php/Main_Page [3] http://bitbake.berlios.de/manual/ [4] http://gnuradio.org/redmine/projects/gnuradio/wiki [5] http://www.python.org [6] BB-xM-SRM-A2-01.pdf [7] USER GUIDE DSP/BIOS™ LINK, LNK 058 USR,Version 1.65.00.02,MAR 30, 2010 [8] PROGRAMMER’S GUIDE DSP/BIOS™ LINK,PROGRAMMER’S GUIDE,LNK 161 USR,Version 1.65.00.02,MAR 30, 2010 [9] https://github.com/alfayez/OMAP-DSP-Main-Wiki/wiki [10] Texas Instrument DSP/BIOS Link OMAP3530 EVM LNK 173 USR Version 1.65.00.03 [11] http://ossie.wireless.vt.edu/trac/wiki/BeagleBoard [12] http://fastr.github.com/articles/booting-the-overo-tide.html [13] Thomas Tsou [14] http://e2e.ti.com/support/embedded/f/354/p/70806/258712.aspx [15] Designing a Software Defined Radio to Run on a Heterogeneous Processor, by Dr. Almohanad S. Fayez [16] http://focus.ti.com/docs/toolsw/folders/print/c6run-dsparmtool.html

73

Importing Open-BTS Software on BeagleBoard

2011

Appendix-A
A.1 Environment Variables for OE

The following environment variables needed to be exported for the OE to work. You can write them in a text file and bash the file before using OE or you can add them to the file “/home/<user_name>/.profile” so that they are automatically exported whenever you log in.
The Environment Variables are: • OEBASE: the path where OE is installed

$ export OEBASE=/path/to/openembedded/

• PATH: this is the directories in which the system searches for executables, it should be modified to add the directory where the Bitbake executable is found.

$ export PATH=$OEBASE/bitbake/bin/:$PATH

• BBPATH: this variable points to the paths where files needed by Bitbake are found.
$ export BBPATH=$OEBASE/build/:$OEBASE/openembedded

74

Importing Open-BTS Software on BeagleBoard

2011

A.2

The configuration file for OE (local.conf)

A sample configuration file “local.conf” is found under the name “local.conf.sample” in “$OEBASE/openembedded/conf/”, you should copy it to “$OEBASE/build/conf/” and edit it before starting using OE. This file contains all the configurations and preferences of OE such as: the image to be built, the target platform, the location of recipes, the type of compression techniques used in the output package(gz, bz2, jffs2, etc.), the providers of the needed packages, etc… The three most important preferences needed for the OE to work are:
• DISTRO: The distribution you want to build or for which the package is built. e.g. DISTRO = ”angstrom-2010.x”. • MACHINE: The target platform e.g. MACHINE = ”beagleboard”. • BBFILES: The path where the recipes to be baked are found. e.g. BBFILES = "$OEBASE/openembedded/recipes/*/*.bb". Here is the sample of “local.conf” provided by OE:
# OpenEmbedded local configuration file (sample) # # Please visit the Wiki at http://openembedded.org/ for more info. # # # Be SURE to read this file in its entirety and the GettingStarted page on the # wiki before proceeding. # # Once you have done that, remove the line at the end of this # file and build away. # # WARNING: lines starting with a space (' ') will result in parse failures. # Remove '# ' from commented lines to activate them. # # NOTE: Do NOT use $HOME in your paths, BitBake does NOT expand ~ for you. If you 75

Importing Open-BTS Software on BeagleBoard

2011

# must have paths relative to your homedir use ${HOME} (note the {}'s there # you MUST have them for the variable expansion to be done by BitBake). Your # paths should all be absolute paths (They should all start with a / after # expansion. Stuff like starting with ${HOME} or ${TOPDIR} is ok). # Use this to specify where BitBake should place the downloaded sources into DL_DIR = "${HOME}/sources" # Delete the line below. Then specify which .bb files to consider for # your build. Typically this will be something like BBFILES = "/path/to/openembedded/recipes/*/*.bb" BBFILES = "/oe/openembedded/openembedded/recipes/*/*.bb" # Use the BBMASK below to instruct BitBake to _NOT_ consider some .bb files # This is a regular expression, so be sure to get your parenthesis balanced. # BBMASK = "/(nonworking|obsolete)/" # Comment this if your host distribution does not provide the # help2man tool. ASSUME_PROVIDED += "help2man-native" # # # # Uncomment this if your host distribution has recent enough Linux Kernel header files. Utilities we use to generate certain types of target filesystems need somewhat recent header files. ASSUME_PROVIDED += "linux-libc-headers-native"

# Uncomment this if you want to use a prebuilt toolchain. You will need to # provide packages for toolchain and additional libraries yourself. You also # have to set PATH in your environment to make sure BitBake finds additional binaries. # ASSUME_PROVIDED += "virtual/${TARGET_PREFIX}gcc virtual/libc" # Uncomment this if you are building Linux 2.4 Embedix kernels. # i.e. openzaurus-sa-2.4.18 and openzaurus-pxa-2.4.18 - and don't forget # to rename the binaries as instructed in the Wiki. # Most users do not need this anymore thankfully! # ASSUME_PROVIDED += "virtual/arm-linux-gcc-2.95" # Select between multiple alternative providers, if more than one is eligible. PREFERRED_PROVIDERS = "virtual/qte:qte virtual/libqpe:libqpe-opie" PREFERRED_PROVIDERS += " virtual/libsdl:libsdl-x11" 76

Importing Open-BTS Software on BeagleBoard
PREFERRED_PROVIDERS cross-initial" PREFERRED_PROVIDERS cross-intermediate" PREFERRED_PROVIDERS PREFERRED_PROVIDERS

2011

+= " virtual/${TARGET_PREFIX}gcc-initial:gcc+= " virtual/${TARGET_PREFIX}gcc-intermediate:gcc+= " virtual/${TARGET_PREFIX}gcc:gcc-cross" += " virtual/${TARGET_PREFIX}g++:gcc-cross"

# Uncomment this to specify where BitBake should create its temporary files. # Note that a full build of everything in OpenEmbedded will take GigaBytes of hard # disk space, so make sure to free enough space. The default TMPDIR is # <build directory>/tmp # Don't use symlinks in in the path to avoid problems # TMPDIR = /usr/local/projects/oetmp # Uncomment this to specify a machine to build for. See the conf directory # for machines currently known to OpenEmbedded. This will automatically take care # of TARGET_ARCH MACHINE = "beagleboard" # Use this to # needed when use # the MACHINE # TARGET_ARCH specify the target architecture. Note that this is only building for a machine not known to OpenEmbedded. Better attribute (see above) = "arm"

# Use this to specify the target operating system. The default is "linux", # for a normal linux system with glibc. Set this to "linux-uclibc" if you want # to build a uclibc based system. # Normally the DISTRO of your choosing will take care of this # TARGET_OS = "linux" # TARGET_OS = "linux-uclibc" # Uncomment this to select a distribution policy. See the conf directory # for distributions currently known to OpenEmbedded. # Although it no longer contain version number in the (file-)name # openzaurus-unstable is a so called "versioned" distro, i.e. they # explicitely select specific versions of various packages. # Stay away from unversioned distros unless you really know what you are doing DISTRO = "angstrom-2010.x" # Uncomment and modify the following lines if you wish to use an external

77

Importing Open-BTS Software on BeagleBoard

2011

# binary toolchain, in this case one built by CodeSourcery. The following # example is for ARM and we set TOOLCHAIN_VENDOR to "-none" as the CodeSourcery # ARM tools are arm-none-linux-gnueabi-$tool. Other arches need different # values here. Some arches may need to override TARGET_PREFIX (ia32). # This assumes that the tools are already in the users PATH. # TOOLCHAIN_VENDOR = "-none" # TOOLCHAIN_TYPE = "external" # TOOLCHAIN_BRAND = "csl" # TOOLCHAIN_PATH = "/path/to/installed/copy/of/CodeSourcery/Sourcery_G++_Lite" # This example is for the Angstrom ARM toolchain, that uses cross prefix of # arm-angstrom-linux-gnueabi-$tool. This assumes that the tools are already # in the users PATH. # TOOLCHAIN_VENDOR = "-angstrom" # TOOLCHAIN_TYPE = "external" # TOOLCHAIN_BRAND = "angstrom" # TOOLCHAIN_PATH = "/usr/local/angstrom/arm" # Uncomment this if you want to use linux-headers from the linux-libcheaders # recipe as opposed to those bundled with the external (csl/angstrom) toolchain # PREFERRED_PROVIDER_linux-libc-headers = "linux-libc-headers" # So far, angstrom.conf sets ENABLE_BINARY_LOCALE_GENERATION # to generate binary locale packages at build time using qemu-native and # thereby guarantee i18n support on all devices. If your build breaks on # qemu-native consider disabling ENABLE_BINARY_LOCALE_GENERATION (note that # this breaks i18n on devices with less than 128MB RAM) or installing # a working third-party qemu (e.g. provided by your distribution) and # adding qemu-native to ASSUME_PROVIDED. Caveat emptor, since thirdparty # qemus lack patches needed to work with various OE targets. # ENABLE_BINARY_LOCALE_GENERATION = "0" # ASSUME_PROVIDED += "qemu-native" # If ENABLE_BINARY_LOCALE_GENERATION is set to "1", you can limit locales # generated to the list provided by GLIBC_GENERATE_LOCALES. This is huge # time-savior for developmental builds. Format: list of locale.encoding pairs 78

Importing Open-BTS Software on BeagleBoard
# with spaces as separators. # GLIBC_GENERATE_LOCALES = "en_US.UTF-8 en_GB.UTF-8 de_DE.UTF-8"

2011

# Uncomment this to select a particular major kernel version if the MACHINE setting # supports more than one major kernel version. Currently this is suported by the # following MACHINE types: poodle, tosa and simpad. # MACHINE_KERNEL_VERSION = "2.6" # # # # Uncomment one of these to build packages during the build process. This is done automatically if you set DISTRO (see above) INHERIT = "package_ipk" INHERIT = "package_tar"

# Add the required image file system types below. Valid are # jffs2, tar(.gz|bz2), cpio(.gz), cramfs, ext2(.gz), ext3(.gz), ext4(.gz|.bz2), # squashfs, squashfs-lzma IMAGE_FSTYPES = "jffs2 tar" # # # # Uncomment this if you want to keep the temporary rootfs directory, this can be useful during development. (Note that this rootfs is NOT usuable as NFS export.) IMAGE_KEEPROOTFS = "1"

# Uncomment this to enable the use of ccache when building. Due to # the nature of our builds this is only helpful in cases when one # is rebuilding a recipe or set of recipes, repeatedly. # CCACHE = "${@bb.which(bb.data.getVar('PATH', d, 1), 'ccache') and 'ccache '}" # Uncomment this to disable the parse cache (not recommended). # CACHE = "" # Uncomment this if you want BitBake to emit debugging output # BBDEBUG = "yes" # Use DEBUG_BUILD to build packages with DEBUG_OPTIMIZATION instead of # FULL_OPTIMIZATION. # # DEBUG_BUILD = "1" # If you want to have unstripped ready-to-debug binaries, set this to "no", # although for debugging you can use automatically produced -dbg packages. # If you need to have completely undebuggable builds, set this to "full", # by default gnu.debuglink section is left in the binaries after stripping, so 79

Importing Open-BTS Software on BeagleBoard
# this might be useful if you want to have checksum-level binary consistency # across successive builds. # PACKAGE_STRIP = "no"

2011

# Uncomment these to build a package such that you can use gprof to profile it. # NOTE: This will only work with 'linux' targets, not # 'linux-uclibc', as uClibc doesn't provide the necessary # object files. Also, don't build glibc itself with these # flags, or it'll fail to build. # # PROFILE_OPTIMIZATION = "-pg" # SELECTED_OPTIMIZATION = "${PROFILE_OPTIMIZATION}" # LDFLAGS =+ "-pg" # Uncomment this to enable parallel make. # This allows make to spawn mutliple processes to take advantage of multiple # processors. Useful on SMP machines. This may break some packages we're # in the process of marking these so let us know if you find any. # PARALLEL_MAKE = "-j 4" # Uncomment to run multiple bitbake threads in parallel. # Bitbake can do multiple jobs in parallel: Its a good idea make use of # all available resources: e.g. to download sources while some other # piece of software is compiled. # BB_NUMBER_THREADS = "2" # Uncomment this if you want BitBake to emit the log if a build fails. BBINCLUDELOGS = "yes" # Uncomment this if you want to install shared libraries directly under their SONAME, # rather than installing as the full version and symlinking to the SONAME. # PACKAGE_SNAP_LIB_SYMLINKS = "1" # EDIT THIS FILE and then remove the line below before using! REMOVE_THIS_LINE:="${@bb.fatal('Read the comments in your conf/local.conf')}"

80

Importing Open-BTS Software on BeagleBoard
A.3 Installing Angstrom on Beagleboard-xM

2011

A.3.1 Getting the files needed for Installation

You will need the following files for installing Angstrom:
• • • • •

u-boot.bin uImage.bin MLO boot.scr The tar image.

1) u-boot.bin: This file is the bootloader, it can be found in: “$OEBASE/build/tmp/deploy/eglibc/armv7a/images/beagleboard/”.

2) uImage.bin: This is the kernel image, it can be found in: “$OEBASE/build/tmp/deploy/eglibc/armv7a/images/beagleboard/”.

3) MLO: This is the x-loader; an x-loader is a small first stage boot loader derived from the u-boot base code to be loaded into the internal static ram by the OMAP ROM code. It can also be found in: “$OEBASE/build/tmp/deploy/eglibc/armv7a/images/beagleboard/”.

81

Importing Open-BTS Software on BeagleBoard
4) Boot.scr:

2011

The “boot.scr” file is needed for Beagleboard-xM since this version of beagleboard doesn’t have ROM memory, so this file is responsible for making the Beagleboard boot from the MMC drive. The “boot.scr” is generated from a “boot.txt” file by using the command:

$ mkimage -A arm -O linux -T script -C none -a 0 -e 0 boot.txt

Here is a sample for how “boot.txt” should look like: “setenv bootcmd 'mmc init; fatload mmc 0 0x80300000 uImage.bin; bootm 0x80300000'
setenv bootargs 'console=ttyS2,115200n8 noinitrd root=/dev/mmcblk0p2 rootfstype=ext3 mem=80M rw rootdelay=1 nohz=off' boot”

5) The tar image: The image is found in: “$OEBASE/build/tmp/deploy/eglibc/armv7a/images/beagleboard/”. You will find a “.tar.bz2” image and “.jffs2” image, we have used the “.tar.bz2” image as it can be untared by using the “tar –xjf” command.

A.3.2 Setting the MMC for installation

The MMC card should have two partitions; one a DOS filesystem FAT16 (about 50MB) and the other a Linux partition ext3 (the rest of the space).

The MMC should be 8GB or more as from searching, developers said that 4GB does not work properly.
82

Importing Open-BTS Software on BeagleBoard

2011

You can do this partitioning by using the “fdisk” command as follows (the MMC device must be unmounted, and you need to be root to use fdisk): • Opening “fdisk”:
$ fdisk /dev/<your_device>

Fig. (A-1), Command actions of fdisk

• Options of fdisk that you will need to use : o p: Print the partition table. o a: Toggle the bootable flag. o d: Delete an existing partition. o n: Add new partition. o l: Show list with known partition types. o t: Change partition type. o w: Write changes to disk and exit.
83

Importing Open-BTS Software on BeagleBoard
The whole set of options is shown in fig. (A-1). To format the partitions you can use the “mkfs.*” command as follows:

2011

• For formatting the Linux partition to ext3 filesystem and naming this partition “rootfs”:
$ mkfs.ext3 –L rootfs /dev/<your_device>

• For formatting the DOS partition to FAT16 filesystem and naming this partition “dosboot”:
$ mkfs.msdos –F 16 –n dosboot /dev/<your_device>

A.3.3 Copying the image files to the MMC

So far you know where the files needed for installation of Angstrom are found and you have partitioned and formatted the MMC card to be suitable for installation. Now you have to copy these files to the MMC card; the tar image is untared in the “rootfs” partition while the other files are copied to the “dosboot” partition as follows: • Untaring the tar image into “rootfs”( “rootfs” should be mounted to /media/rootfs ): o cd into “/media/rootfs”
$ cd /media/rootfs

o Untaring the tar image

$ tar –xjf $OEBASE/build/tmp/deploy/eglibc/images/beagleboard/<the_tar_image>.bz2

84

Importing Open-BTS Software on BeagleBoard
• Copying the other files to “dosboot” ( “dosboot” must be mounted to /media/dosboot): o Copy “u-boot.bin”

2011

$ cp $OEBASE/build/tmp/deploy/eglibc/images/beagleboard/u-boot.bin /media/dosboot/

o Copy “uImage.bin”
$ cp $OEBASE/build/tmp/deploy/eglibc/images/beagleboard/uImage.bin /media/dosboot/

o Copy “MLO”
$ cp $OEBASE/build/tmp/deploy/eglibc/images/beagleboard/MLO /media/dosboot/

o Copy “boot.scr”
$ cp <path_to_boot.scr>/boot.scr /media/dosboot/

85

Importing Open-BTS Software on BeagleBoard Appendix-B
B.1 SAMPLE APPLICATION LOOP Overview

2011

This sample illustrates basic data streaming concepts in DSP/BIOS™ LINK. It transfers data between a task running on GPP and another task running on the DSP. On the DSP side, this application illustrates use of TSK with SIO and SWI with GIO.

Fig. B-1, Data flow in the sample application – LOOP

On the GPP side INITIALIZATION

1. The client sets up the necessary data structures for accessing the DSP. It then attaches to the DSP identified by DSP PROCESSOR IDENTIFIER. 2. It opens the pool to be used for allocating the data transfer buffer(s).
86

Importing Open-BTS Software on BeagleBoard

2011

3. It loads DSP executable (loop.out) on the DSP. 4. It creates channels CHNL_ID_INPUT and CHNL_ID_OUTPUT for data transfer. 5. It allocates and primes buffer(s) of specified size for data transfer on these channels.
EXECUTION

1. The client starts the execution on DSP. 2. It fills the output buffer with sample data. 3. It then issues the buffer on CHNL_ID_OUTPUT and waits to reclaim it. The reclaim is specified to wait forever. 4. The completion of reclaim operation indicates that the buffer has been transferred across the physical link. 5. It issues an empty buffer on CHNL_ID_INPUT and waits to reclaim it. The reclaim is specified to wait forever. 6. Once the buffer is reclaimed, its contents are compared with those of the buffer issued on CHNL_ID_OUTPUT. Since this is a loop back application the contents should be same. 7. The client repeats the steps 3 through 6 for number of times specified by the user. 8. It stops the DSP execution.
FINALIZATION

1. The client frees the buffers allocated for data transfer. 2. It deletes the channels CHNL_ID_INPUT and CHNL_ID_OUTPUT. 3. It closes the pool. 4. It detaches itself from DSP and destroys the PROC component.
On the DSP side (we will look at the initialization, execution and finalization once using TSK with SIO then using SWI with GIO) Using TSK with SIO

87

Importing Open-BTS Software on BeagleBoard

2011

INITIALIZATION

1. The client task tskLoop is created in the function main (). 2. The pool to be used for allocating the data transfer buffers is configured in main() with the buffer size and number of buffers to be allocated. 3. This task creates SIO channels for data transfer - INPUT_CHANNEL and OUTPUT_CHANNEL. 4. It allocates and primes the buffer(s) for to be used for data transfer.
EXECUTION

1. The task issues an empty buffer on INPUT_CHANNEL and waits to reclaim it. The reclaim is specified to wait forever. 2. It then issues the same buffer on OUTPUT_CHANNEL and waits to reclaim it. The reclaim is specified to wait forever. 3. The completion of reclaim operation indicates that the buffer has been transferred across the physical link. 4. These steps are repeated until the number of iterations passed as an argument to the DSP executable is completed.
FINALIZATION

1. The task frees the buffers allocated for data transfer. 2. It deletes the SIO channels INPUT_CHANNEL and OUTPUT_CHANNEL.
Using SWI with GIO INITIALIZATION

1. In the function main (), GIO channels for data transfer - INPUT_CHANNEL and OUTPUT_CHANNEL are created. 2. The pool to be used for allocating the data transfer buffers is configured in main () with the buffer size and number of buffers to be allocated.
88

Importing Open-BTS Software on BeagleBoard

2011

3. A SWI object is created for doing the data transfer. One of the attributes for the SWI object is the callback function loopbackSWI. This function is called when the SWI is posted on completion of READ and WRITE requests on the GIO channels. 4. The buffers for to be used for data transfer are allocated and primed.
EXECUTION

1. To initiate the data transfer a READ request on the input buffer is submitted on the INPUT_CHANNEL. 2. Once the SWI is posted, contents of input buffer are copied to the output buffer. 3. The empty input buffer is reissued onto the input channel and the filled buffer is issued onto the output channel. 4. The SWI is posted again after the completion of both requests. 5. Steps 2 to 4 continue till the time GPP application is issuing buffers.
FINALIZATION

In the sample, the SWI is continuously posted due to READ and WRITE requests. So it would never reach the finalization. The finalization sequence, however, would be: 1. The buffers allocated for data transfer are freed. 2. The GIO channels INPUT_CHANNEL and OUTPUT_CHANNEL are deleted.
Invoking the application

After loading the dsplinkk.ko kernel module on the target platform by this command: [target]$ insmod dsplinkk.ko You can run the loop sample(after copying the loopgpp and loop.out executables from your host environment to your target platform) by this command:
[target]$ ./loopgpp loop.out 1024 10000 0 Where the loop sample takes the following parameters:
89

Importing Open-BTS Software on BeagleBoard
Absolute path of DSP executable ./loop.out Buffer Size 1024 Number of iterations 10000 DSP Processor Id 0

2011

The sample can be executed for infinite iterations by specifying the number of iterations as 0. DSP processor ID is optional argument for single DSP on Linux platforms. For multi dsp, this argument needs to be updated with DSP processor identifier. B.2 Installation of DSPLINK

Follow these steps to install DSPLINK:
B.2.1 Cross compiling TI packages Bitbake Packages

Type the following in your OE environment bitbake ti-codec-engine • Which will not only bake TI's codec engine but the other packages needed: LPM, DSPLink, XDCTool, DSP/BIOS, Code Generation Tools (CGT). The bake will probably failed with an HTTP 404 error where OE couldn't receive a response from the TI server. --2011-06-21 16:32:09-http://install.source.dir.local/ti_cgt_c6000_6.1.17_setup_linux_x86.bin Resolving install.source.dir.local... failed: Name or service not known. wget: unable to resolve host address `install.source.dir.local' --2011-06-21 16:32:14-http://mirrors.openembedded.org//ti_cgt_c6000_6.1.17_setup_linux_x86.bin Resolving mirrors.openembedded.org... 82.197.159.157 Connecting to mirrors.openembedded.org|82.197.159.157|:80... failed: No route to host. --2011-06-21 16:32:17-http://sources.openembedded.org//ti_cgt_c6000_6.1.17_setup_linux_x86.bin
90

Importing Open-BTS Software on BeagleBoard

2011

Resolving sources.openembedded.org... 140.211.169.165 Connecting to sources.openembedded.org|140.211.169.165|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2011-06-21 16:32:17 ERROR 404: Not Found. --2011-06-21 16:32:17-- http://www.angstrom-distribution.org/unstable/sources> /ti_cgt_c6000_6.1.17_setup_linux_x86.bin Resolving www.angstrom-distribution.org... 188.40.83.200 Connecting to www.angstrom-distribution.org|188.40.83.200|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2011-06-21 16:32:18 ERROR 404: Not Found. • The reason is some of the TI software requires users to log in with a user name and password which is okay, if you don't have an account with TI create one ... it's free!
Downloading TI Packages

You can find the URL by looking at the recipe of failed packages, e.g. the Code Generation Tools (DSP Compiler): gedit ../oe/openembedded/recipes/ti/ti-cgt6x.inc The link is in the HOMEPAGE variable at the top of the recipe. In my case HOMEPAGE = "https://wwwa.ti.com/downloads/sds_support/TICodegenerationTools/download.htm" You'll need to download the necessary version of the tools. Looking at the previously quoted error message I need CGT version 6.1.17. • Our recommendation is to copy the files into your files folder cp $HOME/Downloads/ti_cgt_c6000_7.2.2_setup_linux_x86.bin ../oe/openembedded/recipes/ti/files/ • Then open the recipe file for the TI package and point it to the local copy of the needed file gedit ../oe/openembedded/recipes/ti/ti-cgt6x.inc Comment out the following line (by appending a #) SRCURI =

91

Importing Open-BTS Software on BeagleBoard

2011

"http://install.source.dir.local/ti_cgt_c6000${PVwithdots}_setup_linux_x86.bin;n ame=cgt6xbin" and add the following line SRCURI = file://ti_cgt_c6000${PVwithdots}_setup_linux_x86.bin;name=cgt6xbin Continue Bitbaking Packages • Continue baking until all the packages are done and downloading packages manually as necessary into the files folder. bitbak ti-codec-engine B.2.2 Installing TI packages on target platform Setting up U-Boot

In order for DSPLink to function you will need to add a field to your boards boot argument. Basically the linux kernel assumes will assume control over the entire RAM space available, however DSPLink needs to have to use some RAM space not utilized by the kernel for its own purposes. The purpose of the the u-boot modification is to restrict the kernel's memory to some size leaving some unallocated memory space for DSPLink to use. Connect your board over serial connection using your favorite console. As soon as you see the prompt to hit any key to stop the boot process write anything any hit enter

Recognized Tincantools Zippy expansion board (rev 0 0) Beagle Rev C4 Die ID #5caa000400000000040373051401a00e Hit any key to stop auto boot: 3 \0x08\0x08\0x08 2 \0x08\0x08\0x08 0

92

Importing Open-BTS Software on BeagleBoard

2011

To View the current boot argument after interrupting the boot process and back it up in case you need to revert to the old settings print bootargs You need to add a mem field to the bootargs,
o

o

If you're using a platform with onboard NAND, e.g. Beagleboard: setenv bootargs 'console=ttyS2,115200n8 vram=12M omapfb.mode=dvi:1024x768MR-16@60 omapfb.debug=y omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait buddy=zippy mem=80M mpurate=720' saveenv If you're using a board without onboard NAND you will need to update your boot.scr file, or create one if you don't have one, e.g. Gumstix Overo Tide and USRP E100[1][2] Write the following to a text file (myubootenv.cmd) >setenv bootargs 'console=ttyS2,115200n8 vram=12M omapfb.mode=dvi:1024x768MR-16@60 omapfb.debug=y omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait buddy=zippy mem=80M mpurate=720' >setenv bootcmd 'mmc init; run loaduimage; run mmcboot' >boot Run the following in your command console > mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "myubootenv" d myubootenv.cmd boot.scr

o

NOTE: When using the 2.6.39 Linux kernel, the kernel was not able to pickup on the mem=80M parameter from the bootargsparameter which causes DSPLink to crash since the kernel is taking over all available memory. You can check if this is happening by checking on how much memory your kernel is consuming by typing cat /proc/meminfo if you see that the kernel is using up all of your memory then modify the mmcargs variable in u-boot:

93

Importing Open-BTS Software on BeagleBoard
o

2011

o

>setenv mmcargs 'setenv bootargs console=ttyS2,115200n8 vram=12M omapfb.mode=dvi:1024x768MR-16@60 omapfb.debug=y mem=80M omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait buddy=${buddy}' >saveenv

The size of the mem argument depends on your board. For example the Beagleboard has 128MB of RAM therefore mem=80M where the Linux kernel is set to have only 80MB of RAM. If you're using a Gumstix Overo board for example, such as what the USRP E100 uses, amem=464M might be more approapriate since the board has 512MB of RAM. In both cases DSPLink will have 48MB of RAM, this is a good starting value for DSPLink and users can experiment with other values to see what provides the best result/performance.

Installing TI packages

Create a directory on your target platform to copy the packages to be installed mkdir packages Copy the TI packages from your host machine to your target machine cp tmp_dir/deploy/eglibc/ipk/beagleboard/ti-* root@10.0.0.7:/home/root/packages/ The packages of interest to install are o ti-dsplink_1_65_00_03-r102i.9_beagleboard.ipk o ti-cgt6x_6_1_17-r4.9_beagleboard.ipk o ti-codec-engine_2_26_01_09-r102a.9_beagleboard.ipk o ti-dspbios_5_41_07_24-r1.9_beagleboard.ipk o ti-dsplink-examples_1_65_00_03-r102i.9_beagleboard.ipk o ti-lpm-utils_1_24_02_09-r102e.9_beagleboard.ipk o ti-lpm-module_1_24_02_09-r102e.9_beagleboard.ipk o ti-local-power-manager_1_24_02_09-r102e.9_beagleboard.ipk o ti-lpm-utils_1_24_02_09-r102e.9_beagleboard.ipk o ti-xdctools_3_20_06_81-r2.9_beagleboard.ipk
94

Importing Open-BTS Software on BeagleBoard

2011

If you get dependency errors while installing the packages make sure to install the dependent packages first. You can install packages using the following command: opkg install ti-dsplink_1_65_00_03-r102i.9_beagleboard.ipk

Loading the Necessary TI Drivers

When you first install the TI packages, the associated kernel drivers will not be automatically mounted for you.

As a first step, you can verify that the proper drivers are at least in they're right places, go to ls /lib/modules/2.6.39/kernel/drivers/dsp where 2.6.39 might differ according to what kernel you're using. In that directory you should find at least the following: 1. dsplinkk.ko 2. lpm_omap3530.ko The DSPLink directory containing example programs can be found in: cd /usr/share/ti/ti-dsplink-examples
• •

You can load/unload the DSPLink and LPM drivers using o modprobe dsplinkk o modprobe lpm_omap3530 o rmmod dsplinkk.ko o rmmod lpm_omap3530

You can also use the following to check that the modules have been mounted properly: >lsmod Module Size Used by lpm_omap3530 6097 0 dsplinkk 121377 1 lpm_omap3530

95

Importing Open-BTS Software on BeagleBoard

2011

You'll also need to ensure that the LPM driver is loaded insmod /lib/modules/2.6.39/kernel/drivers/dsp/lpm_omap3530.ko

Verifying Your DSPLink Installation

*To make sure that your DSPLink installation is complete run the examples in the TI DSPLink examples directory mentioned above ... for more detailed explanation of the examples look at the DSPLink documentation. *NOTE: If caching is enabled on the DSP then you will have to manually toggle power to the DSP between loading different DSP applications because of a bug in the OMAP3530 processor. You can do so by the LPM utilities: /usr/share/ti/ti-lpm-utils/lpmON.xv5T /usr/share/ti/ti-lpm-utils/lpmOFF.xv5T When using the LPM utilities you should seen a screen output indicating that the power to the DSP has either been turned on or off similar to this root@beagleboard:~/ti-scripts# lpmOFF.xv5T ==== LPM OFF Test ==== app: LPM_open app: LPM_set(LPM_CTRL_REFCOUNTOVR) app: LPM_off app: LPM_close ==== LPM OFF test completed ==== root@beagleboard:~/ti-scripts# lpmON.xv5T ==== LPM ON Test ==== app: LPM_open app: LPM_set(LPM_CTRL_REFCOUNTOVR) app: LPM_on app: LPM_close ==== LPM ON completed ==== If you don't see such output on the screen it means that the utilities installed by the packages might not be the correct version for your kernel, therefore you'll need to copy them manually to your board, you can find them in the following directory:

96

Importing Open-BTS Software on BeagleBoard

2011

*scp oe/tmp/work/beagleboard-angstrom-linux-gnueabi/ti-local-power-manager1_1_24_02_09r102e/local_power_manager_linux_1_24_02_09/packages/ti/bios/power/utils/bin/ti _platforms+evm3530/linux/release/lpm* root@10.0.0.7:/home/root/ti-scripts/ The following is a summary of the different DSPLink example testing root@beagleboard:/usr/share/ti/ti-dsplink-examples# ./loopgpp loop.out 1024 10000 =============== Sample Application : LOOP ========== ==== Executing sample for DSP processor Id 0 ==== Entered LOOP_Create () Leaving LOOP_Create () Entered LOOP_Execute () Transferred 1000 buffers Transferred 2000 buffers Transferred 3000 buffers Transferred 4000 buffers Transferred 5000 buffers Transferred 6000 buffers Transferred 7000 buffers Transferred 8000 buffers Transferred 9000 buffers Transferred 10000 buffers Leaving LOOP_Execute () Entered LOOP_Delete () Leaving LOOP_Delete ()

root@beagleboard:/usr/share/ti/ti-dsplink-examples# lpmOFF.xv5T ==== LPM OFF Test ==== app: LPM_open app: LPM_set(LPM_CTRL_REFCOUNTOVR) app: LPM_off

97

Importing Open-BTS Software on BeagleBoard
app: LPM_close ==== LPM OFF test completed ==== root@beagleboard:/usr/share/ti/ti-dsplink-examples# lpmON.xv5T ==== LPM ON Test ==== app: LPM_open app: LPM_set(LPM_CTRL_REFCOUNTOVR) app: LPM_on app: LPM_close ==== LPM ON completed ==== ========== Sample Application : MESSAGE ========== Entered MESSAGE_Create () Leaving MESSAGE_Create () Entered MESSAGE_Execute () Transferring 10000 iterations took 2 seconds 782715 microseconds. RoundTrip Time for 1 message is 278 microseconds. Leaving MESSAGE_Execute () Entered MESSAGE_Delete () Leaving MESSAGE_Delete ()

2011

root@beagleboard:/usr/share/ti/ti-dsplink-examples# lpmOFF.xv5T ==== LPM OFF Test ==== app: LPM_open app: LPM_set(LPM_CTRL_REFCOUNTOVR) app: LPM_off app: LPM_close ==== LPM OFF test completed ==== root@beagleboard:/usr/share/ti/ti-dsplink-examples# lpmON.xv5T ==== LPM ON Test ==== app: LPM_open app: LPM_set(LPM_CTRL_REFCOUNTOVR) app: LPM_on app: LPM_close ==== LPM ON completed ====
98

Importing Open-BTS Software on BeagleBoard

2011

root@beagleboard:/usr/share/ti/ti-dsplink-examples# ./scalegpp scale.out 1024 40 =============== Sample Application : SCALE ========== Entered SCALE_Create () Leaving SCALE_Create () Entered SCALE_Execute () Changed the scale factor to: 2 Changed the scale factor to: 3 Changed the scale factor to: 4 Leaving SCALE_Execute () Entered SCALE_Delete () Leaving SCALE_Delete ()

root@beagleboard:/usr/share/ti/ti-dsplink-examples# lpmOFF.xv5T ==== LPM OFF Test ==== app: LPM_open app: LPM_set(LPM_CTRL_REFCOUNTOVR) app: LPM_off app: LPM_close ==== LPM OFF test completed ==== root@beagleboard:/usr/share/ti/ti-dsplink-examples# lpmON.xv5T ==== LPM ON Test ==== app: LPM_open app: LPM_set(LPM_CTRL_REFCOUNTOVR) app: LPM_on app: LPM_close ==== LPM ON completed ==== root@beagleboard:/usr/share/ti/ti-dsplink-examples# ./ringiogpp ringio.out 10240 10240 ========== Sample Application : RING_IO ========== Bytes to transfer :10240 Data buffer size :10240 Entered RING_IO_Create () Leaving RING_IO_Create ()
99

Importing Open-BTS Software on BeagleBoard
Entered RING_IO_ReaderClient () Entered RING_IO_WriterClient () GPP-->DSP:Sent Data Transfer Start Attribute GPP-->DSP:Sent Data Transfer Start Notification GPP-->DSP:Bytes Transferred: 8192 GPP<--DSP:Received Data TransferStart Attribute GPP<--DSP:Bytes Received :8192 GPP-->DSP:Total Bytes Transmitted 10240 RingIO_setAttribute succeeded to set the RINGIO_DATA_END. Status = [0x8100] GPP-->DSP:Sent Data Transfer End Attribute GPP-->DSP:Sent Data Transfer End Notification Leaving RING_IO_WriterClient () GPP<--DSP:Received Data TransferEnd Attribute GPP<--DSP:Bytes Received 10240 GPP<--DSP:Received Data Transfer End Notification Leaving RING_IO_ReaderClient () Entered RING_IO_Delete () Leaving RING_IO_Delete ()

2011

root@beagleboard:/usr/share/ti/ti-dsplink-examples# lpmOFF.xv5T ==== LPM OFF Test ==== app: LPM_open app: LPM_set(LPM_CTRL_REFCOUNTOVR) app: LPM_off app: LPM_close ==== LPM OFF test completed ==== root@beagleboard:/usr/share/ti/ti-dsplink-examples# lpmON.xv5T ==== LPM ON Test ==== app: LPM_open app: LPM_set(LPM_CTRL_REFCOUNTOVR) app: LPM_on
100

Importing Open-BTS Software on BeagleBoard

2011

app: LPM_close ==== LPM ON completed ==== root@beagleboard:/usr/share/ti/ti-dsplink-examples# ./readwritegpp readwrite.out 2280587264 1024 1000 ============= Sample Application : READWRITE ========== Entered RDWR_Create () Leaving RDWR_Create () Entered RDWR_Execute () Verified 100 Iterations of Correct Data Read/ Write Verified 200 Iterations of Correct Data Read/ Write Verified 300 Iterations of Correct Data Read/ Write Verified 400 Iterations of Correct Data Read/ Write Verified 500 Iterations of Correct Data Read/ Write Verified 600 Iterations of Correct Data Read/ Write Verified 700 Iterations of Correct Data Read/ Write Verified 800 Iterations of Correct Data Read/ Write Verified 900 Iterations of Correct Data Read/ Write Verified 1000 Iterations of Correct Data Read/ Write Leaving RDWR_Execute () Entered RDWR_Delete () Leaving RDWR_Delete ()

root@beagleboard:/usr/share/ti/ti-dsplink-examples# lpmOFF.xv5T ==== LPM OFF Test ==== app: LPM_open app: LPM_set(LPM_CTRL_REFCOUNTOVR) app: LPM_off app: LPM_close ==== LPM OFF test completed ==== root@beagleboard:/usr/share/ti/ti-dsplink-examples# lpmON.xv5T ==== LPM ON Test ==== app: LPM_open app: LPM_set(LPM_CTRL_REFCOUNTOVR)
101

Importing Open-BTS Software on BeagleBoard

2011

app: LPM_on app: LPM_close ==== LPM ON completed ==== root@beagleboard:/usr/share/ti/ti-dsplink-examples# ./mplistgpp mplist.out 1000 20 ========== Sample Application : MP_LIST ========== Entered MP_LIST_Create () Leaving MP_LIST_Create () Entered MP_LIST_Execute () Verified 100 list based transfer Verified 200 list based transfer Verified 300 list based transfer Verified 400 list based transfer Verified 500 list based transfer Verified 600 list based transfer Verified 700 list based transfer Verified 800 list based transfer Verified 900 list based transfer Verified 1000 list based transfer Leaving MP_LIST_Execute () Entered MP_LIST_Delete () Leaving MP_LIST_Delete ()

root@beagleboard:/usr/share/ti/ti-dsplink-examples# lpmOFF.xv5T ==== LPM OFF Test ==== app: LPM_open app: LPM_set(LPM_CTRL_REFCOUNTOVR) app: LPM_off app: LPM_close ==== LPM OFF test completed ==== root@beagleboard:/usr/share/ti/ti-dsplink-examples# lpmON.xv5T ==== LPM ON Test ==== app: LPM_open
102

Importing Open-BTS Software on BeagleBoard
app: LPM_set(LPM_CTRL_REFCOUNTOVR) app: LPM_on app: LPM_close ==== LPM ON completed ==== root@beagleboard:/usr/share/ti/ti-dsplink-examples# ./messagemultigpp messagemulti.out 100 1 ======= Sample Application : MESSAGEMULTI App [1] ======= App [ 1]: Entered MESSAGEMULTI_Create () App [ 1]: gppMsgqName [GPPMSGQ1] App [ 1]: dspMsgqName [DSPMSGQ1] App [ 1]: PROC_setup status [0x8000] App [ 1]: PROC_attach status [0x8000] App [ 1]: POOL_open MQT_POOL_ID status [0x8000] App [ 1]: MSGQ_open status [0x8000] App [ 1]: PROC_load status [0x8000] App [ 1]: PROC_start status [0x8000] App [ 1]: POOL_open App Pool status [0x8000] App [ 1]: MSGQ_transportOpen status [0x8000] App [ 1]: NOTIFY_register status [0x8000] App [ 1]: NOTIFY_notify status [0x8000] App [ 1]: Leaving MESSAGEMULTI_Create () App [ 1]: Entered MESSAGEMULTI_Execute () App [ 1]: Transferred 100 messages App [ 1]: Leaving MESSAGEMULTI_Execute () App [ 1]: Entered MESSAGEMULTI_Delete () App [ 1]: MSGQ_release status [0x8000] App [ 1]: MSGQ_transportClose status [0x800d] App [ 1]: NOTIFY_unregister status [0x8000] App [ 1]: PROC_stop status [0x8000] App [ 1]: MSGQ_close status [0x8000] App [ 1]: POOL_close App Pool status [0x800d] App [ 1]: POOL_close MQT_POOL_ID status [0x800d] App [ 1]: PROC_detach status [0x8009]

2011

103

Importing Open-BTS Software on BeagleBoard
App [ 1]: PROC_destroy status [0x8008] App [ 1]: Leaving MESSAGEMULTI_Delete () • At this point your DSPLink install should be fully functional !
B.2.3 Setting up DSPLink Framework for GPP/DSP Applications

2011

Even though you have a full installation of all your TI software in your OE temporary directory I would highly suggest making a separate install outside of OE for code development. This way if you delete your OE temp directory you won't delete all your projects with it. Create a direcotry to install your TI software in mkdir /home/alfayez/secondary_hd/ti Copy over the TI software using in making the install packages. For some reason the TI install binaries are not executable by default, so you'll need to make them executable and run them from the command line if they don't launch when you double click on them. Make the binary install files executable: chmod +x ti_cgt_c6000_6.1.1.17_setup_linux_x86.bin chmod +x ti_xdctools_setuplinux_3_20_06_81.bin chmod +x bios_setuplinux_5_41_07_24.bin.bin Run and install each of the above apps from the command line: ./ti_cgt_c6000_6.1.1.17_setup_linux_x86.bin ./ti_xdctools_setuplinux_3_20_06_81.bin ./bios_setuplinux_5_41_07_24.bin. bin Untar DSPLink: tar -xvf dsplink_linux_1_65_00_03.tar.gz

Configuring DSPLink

Setup your environmental variable:
104

Importing Open-BTS Software on BeagleBoard
• •

2011

>export DSPLINK=/home/alfayez/secondary_hd/ti/dsplink_1_65_00_03/dsplink >export C6X_C_DIR="/home/alfayez/secondary_hd/ti/cgt_c6000_6_1_17/include:/ho me/alfayez/secondary_hd/ti/cgt_c6000_6_1_17/lib" >export XDC_INSTALL_DIR=/home/alfayez/secondary_hd/ti/xdctools_3_20_06_81 Build DSPLink by typing the following: > cd dsplink/config/bin > perl dsplinkcfg.pl --platform=OMAP3530 --nodsp=1 -dspcfg_0=OMAP3530SHMEM --dspos_0=DSPBIOS5XX -gppos=OMAPLSP --comps=ponslrmc --trace=1 Next you will need to modify 3 Makefiles to allow DSPLink to find your cross compile tools, headers, libraries, ... etc. $DSPLINK/make/Linux/omap3530_2.6.mk $DSPLINK/gpp/src/Rules.mk $DSPLINK/make/DspBios/c64xxp_5.xx_linux.mk You probably should make backups of all these files before modifying them. Also there can be some minor modifications to the variable settings with DSPLink and/or OE updates so you might need to further tweak the provided values to suit your setup

• • •

• • • •

Changes to omap3530_2.6.mk

BASE_BUILDOS:= ${HOME}/secondary_hd/oe/tmp_beagleboard/sysroots/beagleboard-angstromlinux-gnueabi/kernel BASE_TOOLCHAIN:= ${HOME}/secondary_hd/oe/tmp_beagleboard/sysroots/i686-linux/usr/armv7a

105

Importing Open-BTS Software on BeagleBoard

2011

OSINC_PLATFORM := $(BASE_TOOLCHAIN)/lib/gcc/arm-angstrom-linuxgnueabi/4.5.3/include OSINC_TARGET := $(BASE_TOOLCHAIN)/arm-angstrom-linuxgnueabi/include/c++/4.5.3 COMPILER := $(BASE_CGTOOLS)/arm-angstrom-linux-gnueabi-gcc LD := $(BASE_CGTOOLS)/arm-angstrom-linux-gnueabi-ld CROSS_COMPILE := $(BASE_CGTOOLS)/arm-angstrom-linux-gnueabiARCHIVER := $(BASE_CGTOOLS)/arm-angstrom-linux-gnueabi-ar LINKER := $(BASE_CGTOOLS)/arm-angstrom-linux-gnueabi-gcc

Changes to Rules.mk
• •

Change the following under the OMAP3530 platform: KERNEL_DIR := ${HOME}/secondary_hd/oe/tmp_beagleboard/sysroots/beagleboardangstrom-linux-gnueabi/kernel TOOL_PATH := ${HOME}/secondary_hd/oe/tmp_beagleboard/sysroots/i686-linux/usr/armv7a These changes come further down in the file, since I'm not using uC libraries I modify the two variables that come at the end of the file: CG_PREFIX = arm-angstrom-linux-gnueabiMAKE_OPTS = ARCH=arm CROSS_COMPILE=$(TOOL_PATH)/bin/armangstrom-linux-gnueabi-

• •

Changes to c64xxp_5.xx_linux.mk

BASE_INSTALL := ${HOME}/secondary_hd/ti BASE_SABIOS := $(BASE_INSTALL)/bios_5_41_07_24 XDCTOOLS_DIR := $(BASE_INSTALL)/xdctools_3_20_06_81 BASE_CGTOOLS := $(BASE_INSTALL)/cgt_c6000_6_1_17

106

Importing Open-BTS Software on BeagleBoard
Run these commands
• • • • • •

2011

cd into the $(DSPLINK)/dsp and run the following: $XDC_INSTALL_DIR/xdc clean $XDC_INSTALL_DIR/xdc .interfaces cd into the $(DSPLINK)/gpp and run the following: $XDC_INSTALL_DIR/xdc clean $XDC_INSTALL_DIR/xdc .interfaces

Rebuild Existing DSPLink Code
• •

Now we will recompile all of the DSPLink GPP and DSP source code which will test whether or not the GPP/DSP compile environment is setup correctly. cd into cd $DSPLINK/dsp/src and run the following: make -s clean make -s debug make -s release cd into cd $DSPLINK/dsp/src/samples make -s clean make -s debug make -s release o NOTE: If you get any compile errors during the compilation of either the DSP or GPP code then you probably made a mistake in the makefiles that you've configured easly on. If the compilation went smoothly then your DSP build environment is FINALLY setup. Next let's check on the GPP environment, cd into $DSPLINK/gpp/src and run the following: make -s clean make -s debug make -s release
107

• •

Importing Open-BTS Software on BeagleBoard
o

2011

NOTE: Depending on what kernel you're using you might get a build error at this step saying: Building kernel side code using kbuild /home/alfayez/secondaryhd/ti/dsplink_1_65_00_03/dsplink/gpp/src/../../gpp/sr c/pmgr/Linux/2.6.18/drv_pmgr.c:498:5: error: unknown field 'ioctl' specified in initializer /home/alfayez/secondary_hd/ti/dsplink_1_65_00_03/dsplink/gpp/src/../../gpp/s rc/pmgr/Linux/2.6.18/drv_pmgr.c:498:5: warning: initialization from incompatible pointer type make[2]: *** [/home/alfayez/secondary_hd/ti/dsplink_1_65_00_03/dsplink/gpp/src/../../gpp/ src/pmgr/Linux/2.6.18/drv_pmgr.o] Error 1 make[1]: *** [_module/home/alfayez/secondary_hd/ti/dsplink_1_65_00_03/dsplink/gpp/src] Error 2 make: *** [debug] Error 2 This error only affects the recompilation of the DSPLink driver which is not necessary if you don't plan on modifying the underlying architecture of DSPLink ... but for completeness sake this is how you fix this issue [1].

There is a patch in your OE recipe directory to solve this issue in: $(OE_HOME)/openembedded/recipes/ti/ti-dsplink/dsplink-BKL-fix.patch

and the file with the problem is in: >$(DSPLINK)/gpp/src/pmgr/Linux/2.6.18/drv_pmgr.c you can either apply the patch to the file or just copy over the patched file from your OE temp directory: >$(OE)/tmp/work/beagleboard-angstrom-linux-gnueabi/ti-dsplink1_1_65_00_03r102i/dsplink_linux_1_65_00_03/dsplink/gpp/src/pmgr/Linux/2.6.18/drv_pmgr.c

After you finish compiling the code here, you've successfully recompiled the DSPLink driver.
108

Importing Open-BTS Software on BeagleBoard
• • • • •

2011

The next step is to recompile the DSPLink GPP side examples ... cd $(DSPLINK)/gpp/src/samples make -s clean make -s debug make -s release

Where Are My Executables and Newly Compiled Driver?

* GPP Executbales >$(DSPLINK)/gpp/BUILD/EXPORT/DEBUG >$(DSPLINK)/gpp/BUILD/EXPORT/RELEASE * DSPLink Driver >$(DSPLINK)/gpp/export/BIN/Linux/OMAP3530/DEBUG >$(DSPLINK)/gpp/export/BIN/Linux/OMAP3530/RELEASE * DSP Executables >$(DSPLINK)/dsp/BUILD/OMAP3530_0/EXPORT/DEBUG >$(DSPLINK)/dsp/BUILD/OMAP3530_0/EXPORT/RELEASE

B.3 Installation of C6Run

When C6EZRun is built as part of a distribution, such as Angstrom, all required dependent components are satisfied by the OpenEmbedded recipes. The kernel modules should have been built with their related dependent components, and therefore should already be present. There are several ways to get the C6EZRun software , The one discussed here is the Stand-alone download, for other methods you can visit Texas C6Run Wiki in this link: http://processors.wiki.ti.com/index.php/Getting_Started_With_C6EZRun

109

Importing Open-BTS Software on BeagleBoard
B.3.1 Stand-alone Download

2011

The latest packaged, stand-alone release is available from the TI website: http://focus.ti.com/docs/toolsw/folders/print/c6run-dsparmtool.html, we have tried 2 versions so far, one of them gave some errors about missing header files - in the make dsp_libs step in the Stand-alone setup (discussed later) - which is the C6run Version _0_97_02_02, but C6run Version _0_95_01_01 worked just fine. These dependencies need to be downloaded and installed along the C6Run to be able to get C6Run to work: • DSP/BIOS 5 real-time operating system • DSPLink • XDCtools Package • Linux Utils Package • Local Power Manager (LPM) for Linux (FOR OMAP3 PLATFORMS ONLY)

Users who want to work with Syslink vs Dsplink can visit the Texas C6run Wiki link given above for list of the required dependencies. C6EZRun also require the proprietary C6000 Code Generation Tools from Texas Instruments and a GCC cross compiler for the ARM architecture. These tools may be required to be downloaded ,

110

Importing Open-BTS Software on BeagleBoard
Dependency Version

2011
Direct Download Link

TI C6000 Codegen Tools

www.a.ti.com/do v6.1.x, v7.0.x, v7.2.2 or wnloads/sds_sup higher (v7.2.0 and port/TICodegener v7.2.1 are not ationTools/downl compatible) oad.htm

ARM Cross Compiler tools. Older targets http://www.codes may also require the Montavista GCC cross- 2009q1 (later versions ourcery.com/sgpp compiler tools, as delivered in SDKs and/or may work) /lite/arm/portal/su LSPs from TI. bscription3057 For our luck, the top-level makefile in the package can be used to automatically retrieve all required dependencies (discussed below) except for the Compilers which need to be downloaded/installed manually so you wont need to download/install each dependency one by one unless one of the dependencies refused to be downloaded which can sometimes happen, then you have to manually do it. The links for downloading each dependency alone can be found on the TI C6Run Wiki.

B.3.1.1 Stand-alone Setup

Follow these steps in order to setup C6EZRUN: • Un-tar the C6EZRun install package to some location on your host Linux system (note that <MM>_<mm>_<pn>_<bn> reflects the version number of the package). [host]$ tar -xvzf C6Run_<MM>_<mm>_<pn>_<bn>.tar.gz Enter into the top-level directory of the package [host]$ cd C6Run_<MM>_<mm>_<pn>_<bn>

111

Importing Open-BTS Software on BeagleBoard

2011

• Get and install the required dependencies listed previously (except the compilers - these must be downloaded and installed manually). The easiest way to get these components is to use the 'make get_components' command. It uses the wget utility on your Linux host system to download and install the components in the C6Run top-level path. It should be run from within the C6Run_<MM>_<mm>_<pn>_<bn> directory. If you want to use any other versions of the dependent components, then you can edit the Rules.mak file to specify different version numbers before running this step. [host]$ make get_components Edit the Rules.mak file at the top-level of the package. Make sure all paths are correctly specified to point to the install location for the various dependencies given above. If you used the get_components target (above), all the variables in this file are already correct, except for the Compilers variables which you need to change to point to where you installed these compilers. A copy of our edited Rules.mak can be found in Appendix C, it has different versions than the original Rules.mak downloaded from TI website , these are the versions that we experimented with, but the ones from the original Rules.mak should work just fine as well. For your targeted platform, edit: platforms/<PLATFORM_NAME>/platform.mak file to reflect the location of the u-boot and linux kernel sources (needed for building any required Linux kernel modules). Generally speaking, you shouldn't need to edit anything further in this file. • Configure for your desired platform (run 'make help' to see available platforms) [host]$ make <platform>_config For example as we used beagleboard-xM platform so we did: [host]$ make beagleboard-xM_config .

If you wish to alter the physical memory that the C6EZRun software will use, you
112

Importing Open-BTS Software on BeagleBoard

2011

can provide the following variables when running the config step: DSP_REGION_BASE_ADDR=0xZZZZZZZZ, DSP_REGION_CMEM_SIZE=0xZZZZZZZZ, DSP_REGION_CODE_SIZE=0xZZZZZZZZ. For example, the following command will indicate that the DSP reqion begins at 0xC6000000, with the CMEM region being 16MB (0x01000000) in size, and the DSP code region also being 16MB (0x01000000). Then the total region in use by the C6Run framework will be from 0xC6000000 to 0xC8000000. [host]$ make DSP_REGION_BASE_ADDR=0xC6000000 DSP_REGION_CMEM_SIZE=0x01000000 DSP_REGION_CODE_SIZE=0x01000000 <platform>_config • (OPTIONAL) If you do not have a built kernel tree, you can use the C6Run make system to build it (note that the kernel and uboot directories in platform.mak must be correct). A built kernel tree is required to build the kernel modules in the next step. [host]$ make linux Next you'll have to change some variables in platform.mak in order to proceed to the next step, these are ARM_TOOLCHAIN_PATH ARM_TOOLCHAIN_PREFIX = PATH OF SOURCERY_G++_LITE = arm-none-linux-gnueabi-

LINUXKERNEL_INSTALL_DIR ?= THE KERNEL UPER DIRECTORY OF OPENEMBEDDED Our edited platform.mak can be found in Appendix C • From the top-level of the C6Run install location run 'make everything'. [host]$ make everything This may take some time and there will be a lot of output on the screen. If something goes wrong, you can build the following targets separately to get an idea
113

Importing Open-BTS Software on BeagleBoard
of where the build failure originated: • Clean and build DSP-side back-end C6Run library: [host]$ make dsp_libs • Clean and build ARM-side back-end C6Run library: [host]$ make gpp_libs If you got an error in this step stating something like that:

2011

/bin/sh: line 2: /root/C6run/C6Run_0_95_01_01/bin/-ar: No such file or directory make[2]: *** [DebugPrep] Error 127 then your ARM_TOOLCHAIN variables in platform.mak are set incorrectly • Clean and build CMEM and DSPLink kernel modules: [host]$ make modules If you got an error in this step stating something like that: Cleaning up LPM kernel module...make: *** /root/angstrom-setupscripts/build/tmp-angstrom_2008_1/sysroots/beagleboard-angstrom-linuxgnueabi/kernel: No such file or directory. Stop. Then your LINUXKERNEL_INSTALL_DIR variable in platform.mak is set incorrectly. • If you intend to build any of the included test cases or examples, you can do one of two things: • Add the <C6Run Install Path>/bin directory and the bin directory of the ARM cross-compiler tool to the system path. If not using the CodeSourcery ARM GCC tools, you will also need to specify the environment variable ARM_TOOLCHAIN_PREFIX to contain the correct GCC cross compiler prefix. The specifics of how to do this may vary from one Linux distribution to another. For Ubuntu, see here. For other systems, adding profile scripts to
114

Importing Open-BTS Software on BeagleBoard

2011

the directory /etc/profile.d or by creating/editing the ~/.bash_profile, ~/.bash_login, or ~/.profile files. The assumption is that the user is using the typical BASH shell on their Linux host. • Run the following: [host]$ source environment.sh This will put all required variables into the current environment based on the configuration provided at build time. If you exit your terminal window and then open a new one, you will need to re-run this command to get these environment variables back (they aren't permanent). • (OPTIONAL) Build the included example projects. [host]$ make examples • (OPTIONAL) Build the included test cases. [host]$ make tests • (OPTIONAL) Install the test cases, examples, and run-time scripts to a specified path (typically a shared target filesystem path). [host]$ make INSTALL_DIR=<desired install path> install_programs

B.3.2 Steps for Running C6Run programs on target platform:

1. Setup your platform for booting to Linux kernel using a root file system you provide (information on how to do this is beyond the scope of this project, but typically consists of getting u-boot loaded and running, configuring boot arguments for the Linux kernel under u-boot, and then initiating the kernel boot process from u-boot). IMPORTANT: You need to use the appropriate 'mem=' bootarg for the kernel, so that Linux kernel will not use the memory that the C6Run expects to use in the memory map. This information is shown when the make <platform>_config step is performed. The physical memory region that C6Run uses can be altered per the
115

Importing Open-BTS Software on BeagleBoard
instruction done earlier:

2011

[host]$make DSP_REGION_BASE_ADDR=0xC6000000 DSP_REGION_CMEM_SIZE=0x01000000 DSP_REGION_CODE_SIZE=0x01000000 <platform>_config 2. Copy the kernel modules (*.ko) and the module loading and unloading scripts (*.sh) to your target's filesystem from the C6Run/platforms/<platform> path. If you ran this command earlier: make INSTALL_DIR=<desired install path> install_programs, you'll find all these files in the <desired install path> that you have created 3. 4. 5. Copy any executables that you have built using the C6Run tools to your target's file system. Boot the system. Login, locate and run the loadmodules.sh script. [target]$ ./loadmodules.sh

Run any one program that you have created with the C6Run tools. Only one program can use the DSP at a time. As an example, you can run hello_world_arm by typing: [target]$ ./hello_world_arm But to run the hello_world_dsp, you will have to give certain memory map arguments while inserting the cmemk.ko module in order not to have memory interference between the memory that Linux kernel is using and the one that the dsplink uses. So instead of loading modules by invoking ./loadmodules.sh, you'll have to insert each module alone, as shown: [target]$ insmod dsplink.ko [target]$insmod cmemk.ko phys_start=0x88000000 pools=2x4100000,10x1100000,50x130000,100x17000 [target]$ insmod lpm_omap3530.ko
116

phys_end=0xa0000001,

Importing Open-BTS Software on BeagleBoard

2011

choose phys_start and phys_end values to match your new CMEM address and size, and specify pools to match the buffer requirement of your application. For an overview on cmemk.ko visit this website : http://processors.wiki.ti.com/index.php/CMEM_Overview You can unload a module anytime by invoking the command rmmod. For each sample program, you'll have to calculate the required memory usage by the program and change the arguments of cmemk.ko module accordingly.
B.3.3 How to make your own C6Run application using C6Run Makefiles:

If you want to make your own application fast without having to dive into details of compilation of C6run explained at the beginning of this chapter You can do the following: 1- make a new folder inside the examples/c6runapp directory which will contain your own application 2- Copy one of the make files found inside c6runapp examples, lets say hello_world for example, to the new folder created above after changing PROJNAME instead of hello_world to <your application> name 3- make your own c file and save it as <your application>.c 4- go back to the C6run main directory and run make examples , which will compile all the C6run examples including your application 5- enter into your application folder, you should find <your application>_arm and <your application>_dsp executables there.

117

Sign up to vote on this title
UsefulNot useful