DOCSLIB.ORG

(DSP) Application Development System (ADS) User's Manual

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

GENERAL INFORMATION 1 HARDWARE INSTALLATION 2 USER INTERFACE COMMANDS 3 ADS GRAPHICAL USER INTERFACE 4 FUNCTIONAL DESCRIPTION 5 HOST CARD / COMMAND CONVERTER 6 MOTOROLA OBJECT MODULE FORMAT (OMF) A MOTOROLA OBJECT FILE FORMAT (COFF) B MOTOROLA S-RECORD INFORMATION C C LIBRARY FUNCTIONS D INDEX I 1 GENERAL INFORMATION 2 HARDWARE INSTALLATION 3 USER INTERFACE COMMANDS 4 ADS GRAPHICAL USER INTERFACE 5 FUNCTIONAL DESCRIPTION 6 HOST CARD / COMMAND CONVERTER A MOTOROLA OBJECT MODULE FORMAT (OMF) B MOTOROLA OBJECT FILE FORMAT (COFF) C MOTOROLA S-RECORD INFORMATION D C LIBRARY FUNCTIONS I INDEX DIGITAL SIGNAL PROCESSOR (DSP) Application Development System (ADS) User’s Manual PRELIMINARY Motorola, Incorporated Semiconductor Products Sector Wireless Signal Processing Division 6501 William Cannon Drive West Austin, TX 78735-8598 This document (and other documents) can be viewed on the World Wide Web at http://www.motorola-dsp.com. OnCE is a trademark of Motorola, Inc. MOTOROLA INC., 1989, 1997 Order this document by DSPADSUM/AD Motorola reserves the right to make changes without further notice to any products herein to improve reliability, function, or design. Motorola does not assume any liability arising out of the application or use of any product or circuit described herein; neither does it convey any license under its patent rights nor the rights of others. Motorola products are not authorized for use as components in life support devices or systems intendedPRELIMINARY for surgical implant into the body or intended to support or sustain life. Buyer agrees to notify Motorola of any such intended end use whereupon Motorola shall determine availability and suitability of its product or products for the use intended. Motorola and are registered trademarks of Motorola, Inc. Motorola, Inc. is an Equal Employment Opportunity /Affirmative Action Employer. TABLE OF CONTENTS 1.1 INTRODUCTION . 1-3 1.2 GENERAL DESCRIPTION. 1-4 1.3 OPERATING ENVIRONMENT. 1-6 1.3.1 PC-Compatible Requirements . 1-6 1.3.2 Hewlett Packard HP7xx Workstation Requirements . 1-7 1.3.3 Sun-4 or Compatible Workstation Requirements . 1-7 1.4 ADS SOFTWARE FEATURES . 1-8 1.5 TEXT-BASED USER INTERFACE . 1-9 1.5.1 General Description . 1-9 1.5.2 Command Entry. 1-9 1.5.3 Display Modes . 1-10 1.6 GETTING STARTED . 1-11 2.1 HOST COMPUTER INTERFACE CARD . 2-3 2.2 PC-COMPATIBLE TO COMMAND CONVERTER INTERFACE 2-3 2.2.1 Installing the PC-Compatible Interface . 2-3 2.3 INSTALLING THE PC-COMPATIBLE SOFTWARE . 2-5 2.3.1 Defining Environment Variables . 2-5 2.3.2 All Versions of User-Interface Program . 2-6 2.3.3 Text-Based User Interface Program Installation . 2-6 2.3.4 Using Default Settings . 2-7 2.3.5 Graphical User Interface (GUI) Program Installation . 2-7 2.4 SUN 4 TO COMMAND CONVERTER INTERFACE . 2-8 2.4.1 Installing the Sun-4 Interface . 2-8 2.4.2 Software Installation . 2-9 2.5 HP7XX TO COMMAND CONVERTER INTERFACE. 2-10 2.5.1 Installing the HP-7xx Interface. 2-10 2.5.1.1PRELIMINARY HP VUE Shutdown . 2-10 2.5.1.2 HP-UX COMMAND LINE SHELL SHUTDOWN . 2-10 2.5.1.3 ISA Card Installation . 2-11 2.5.2 Installing the HP-7xx Device Driver . 2-12 2.6 CONFIGURING THE COMMAND CONVERTER . 2-16 2.6.1 Selecting the Command Converter Device Number . 2-16 MOTOROLA DSPADSUM/AD iii 2.6.2 JTAG/OnCE Port Buffer VCC . .2-17 2.6.3 Command Convertor Monitor Firmware Upgrades . .2-17 3.1 INTRODUCTION . .3-3 3.2 COMMAND OVERVIEW . .3-3 3.2.1 Memory/Register Display/Modification Commands . .3-3 3.2.2 File I/O Commands . .3-3 3.2.3 Target Program Execution Commands. .3-4 3.2.4 C Source Code Debug Commands. .3-4 3.2.5 Command Converter Commands . .3-4 3.2.6 Miscellaneous Commands . .3-4 3.3 COMMAND SYNTAX . .3-5 3.4 COMMAND PARAMETERS . .3-7 3.5 COMMAND SUMMARY . .3-8 3.6 DETAILED COMMAND DESCRIPTIONS . .3-12 3.6.1 ASM—Single Line Interactive Assembler . .3-12 3.6.2 BREAK—Set, Modify, or Clear Breakpoint . .3-14 3.6.3 CCHANGE—Change Command Converter Memory . .3-23 3.6.4 CDISPLAY—Display Command Converter Flags and Memory . .3-24 3.6.5 CFORCE—Assert Reset or Break on Command Converter.3-25 3.6.6 CGO—Execute OnCE Sequence . .3-26 3.6.7 CLOAD—Load OnCE Command Sequence. .3-27 3.6.8 CSAVE—Save Command Converter Memory to a File . .3-28 3.6.9 CSTEP—Step through OnCE Sequence . .3-29 3.6.10 CTRACE—Trace through OnCE Sequence . .3-30 3.6.11 CHANGE—Change Register or Memory Value . .3-31 3.6.12 COPY—Copy a Memory Block . .3-33 3.6.13 DEVICE—Select Default target DSP address . .3-34 3.6.14 DISASSEMBLE—Single Line Disassembler. .3-36 3.6.15 DISPLAY—Display Register or Memory. .3-37 3.6.16PRELIMINARY DOWN—Move Down the C Function Call Stack. .3-39 3.6.17 EVALUATE—Evaluate an Expression . .3-40 3.6.18 FINISH—Step Until End of Current Subroutine . .3-41 3.6.19 FORCE—Assert RESET or BREAK on Target. .3-42 3.6.20 FRAME—Select C Function Call Stack Frame. .3-43 3.6.21 GO—Execute DSP Program. .3-44 iv DSPADSUM/AD MOTOROLA 3.6.22 HELP—ADS User Interface Help Text . 3-45 3.6.23 HOST—Change HOST Interface Address . 3-46 3.6.24 INPUT—Assign Input File . 3-47 3.6.25 LIST—List Source File Lines . 3-51 3.6.26 LOAD—Load DSP Program . 3-52 3.6.27 LOG—Log Commands and/or Session . 3-54 3.6.28 MORE—Enable/Disable Session Paging Control . 3-55 3.6.29 NEXT—Step Over Subroutine Calls or Macros . 3-56 3.6.30 OUTPUT—Assign Output File . 3-57 3.6.31 PATH—Define File Directory Path. 3-60 3.6.32 QUIT—Exit ADS Program . 3-61 3.6.33 RADIX—Change Default Number Base . 3-62 3.6.34 REDIRECT—Redirect stdin/stdout/stderr for C Programs . 3-63 3.6.35 SAVE—Save Memory To File . 3-64 3.6.36 STEP—Step Through DSP Program. 3-65 3.6.37 STREAMS—Enable/Disable Handling of I/O for C Programs . 3-66 3.6.38 SYSTEM—Operating System Access . 3-67 3.6.39 TRACE—Trace Through DSP Program . 3-68 3.6.40 TYPE—Display The Result Type of C Expression . 3-69 3.6.41 UNLOCK—Unlock Password Protected Device Type . 3-70 3.6.42 UNTIL—Step Until Address . 3-71 3.6.43 UP- Move Up the C Function Call Stack . 3-72 3.6.44 VIEW- Select Display Mode. 3-73 3.6.45 WAIT—Wait Specified Time . 3-74 3.6.46 WATCH—Set, Modify, View, or Clear Watch Item . 3-75 3.6.47 WASM—GUI Assembly Window . 3-76 3.6.48 WBREAKPOINT—GUI Breakpoint window . 3-77 3.6.49 WCALLS—GUI C Calls Stack Window . 3-78 3.6.50 WCOMMAND—GUI Command Window . 3-79 3.6.51PRELIMINARY WHERE—GUI C Calls Stack Window . 3-80 3.6.52 WINPUT—GUI File Input window . 3-81 3.6.53 WLIST—GUI List Window . 3-82 3.6.54 WMEMORY—GUI Memory Window . 3-83 3.6.55 WOUTPUT—GUI File Output Window . 3-84 3.6.56 WREGISTER—GUI Register Window. 3-85 MOTOROLA DSPADSUM/AD v 3.6.57 WSESSION—GUI Session Window . .3-86 3.6.58 WSOURCE—GUI Source window . .3-87 3.6.59 WSTACK—GUI Stack Window. .3-88 3.6.60 WWATCH—GUI watch window . .3-89 3.7 DEBUGGING C PROGRAMS . .3-90 3.7.1 C Debug Features. .3-90 3.7.2 C Expressions. .3-90 3.7.3 Restrictions . .3-91 3.7.4 Compiling a Program for Debugging. .3-92 3.8 C DEBUGGING COMMANDS. .3-92 3.9 EXAMPLE DEBUGGING SESSIONS . .3-92 3.9.1 Binary Search Example. .3-93 3.9.2 Recursive Binary Tree Traversal Example . .3-96 4.1 INTRODUCTION . .4-3 4.2 HOST SYSTEM REQUIREMENTS. .4-3 4.3 PLATFORM SPECIFICS . .4-3 4.4 GENERAL WINDOW BEHAVIOR . .4-4 4.4.1 File Chooser . .4-4 4.4.2 Multiple Operations . .4-5 4.4.3 MULTIPLE SELECTIONS. .4-6 4.5 GRAPHICAL INTERFACE FUNCTIONS OVERVIEW . .4-6 4.5.1 GUI Structure . .4-7 4.5.2 Starting the ADS . .4-7 4.5.3 File Access Paths . .4-8 4.5.4 Loading Object Files . .4-8 4.5.5 Examining and Changing Memory . .4-8 4.5.6 Examining and Changing Registers . .4-9 4.5.7 Program Execution—the Tool Bar . .4-9 4.5.8 Device Selection . ..
Recommended publications
  • Linux Kernal II 9.1 Architecture

    Linux Kernal II 9.1 Architecture

    Page 1 of 7 Linux Kernal II 9.1 Architecture: The Linux kernel is a Unix-like operating system kernel used by a variety of operating systems based on it, which are usually in the form of Linux distributions. The Linux kernel is a prominent example of free and open source software. Programming language The Linux kernel is written in the version of the C programming language supported by GCC (which has introduced a number of extensions and changes to standard C), together with a number of short sections of code written in the assembly language (in GCC's "AT&T-style" syntax) of the target architecture. Because of the extensions to C it supports, GCC was for a long time the only compiler capable of correctly building the Linux kernel. Compiler compatibility GCC is the default compiler for the Linux kernel source. In 2004, Intel claimed to have modified the kernel so that its C compiler also was capable of compiling it. There was another such reported success in 2009 with a modified 2.6.22 version of the kernel. Since 2010, effort has been underway to build the Linux kernel with Clang, an alternative compiler for the C language; as of 12 April 2014, the official kernel could almost be compiled by Clang. The project dedicated to this effort is named LLVMLinxu after the LLVM compiler infrastructure upon which Clang is built. LLVMLinux does not aim to fork either the Linux kernel or the LLVM, therefore it is a meta-project composed of patches that are eventually submitted to the upstream projects.
  • DSP56303 Product Brief, Rev

    DSP56303 Product Brief, Rev

    Freescale Semiconductor DSP56303PB Product Brief Rev. 2, 2/2005 DSP56303 24-Bit Digital Signal Processor 16 6 6 3 Memory Expansion Area The DSP56303 is intended Triple X Data HI08 ESSI SCI PrograM Y Data for use in telecommunication Timer RAM RAM RAM 4096 × 24 2048 × 24 2048 × 24 applications, such as multi- bits bits bits line voice/data/ fax (default) (default) (default) processing, video Peripheral Expansion Area conferencing, audio PM_EB XM_EB PIO_EB YAB YM_EB applications, control, and Address External 18 Generation XAB Address general digital signal Unit PAB Bus Address Six-Channel DAB Switch processing. DMA Unit External 24-Bit Bus 13 Bootstrap DSP56300 Interface ROM and Inst. Core Cache Control Control DDB 24 Internal YDB External Data XDB Data Bus Bus PDB Switch Data Switch GDB EXTAL Power Clock Management Data ALU 5 Generator Program Program Program × + → XTAL Interrupt Decode Address 24 24 56 56-bit MAC JTAG PLL Two 56-bit Accumulators Controller Controller Generator 56-bit Barrel Shifter OnCE™ DE 2 MODA/IRQA MODB/IRQB RESET MODC/IRQC PINIT/NMI MODD/IRQD Figure 1. DSP56303 Block Diagram The DSP56303 is a member of the DSP56300 core family of programmable CMOS DSPs. Significant architectural features of the DSP56300 core family include a barrel shifter, 24-bit addressing, instruction cache, and DMA. The DSP56303 offers 100 million multiply-accumulates per second (MMACS) using an internal 100 MHz clock at 3.0–3.6 volts. The DSP56300 core family offers a rich instruction set and low power dissipation, as well as increasing levels of speed and power to enable wireless, telecommunications, and multimedia products.
  • Low Power Asynchronous Digital Signal Processing

    Low Power Asynchronous Digital Signal Processing

    LOW POWER ASYNCHRONOUS DIGITAL SIGNAL PROCESSING A thesis submitted to the University of Manchester for the degree of Doctor of Philosophy in the Faculty of Science & Engineering October 2000 Michael John George Lewis Department of Computer Science 1 Contents Chapter 1: Introduction ....................................................................................14 Digital Signal Processing ...............................................................................15 Evolution of digital signal processors ....................................................17 Architectural features of modern DSPs .........................................................19 High performance multiplier circuits .....................................................20 Memory architecture ..............................................................................21 Data address generation .........................................................................21 Loop management ..................................................................................23 Numerical precision, overflows and rounding .......................................24 Architecture of the GSM Mobile Phone System ...........................................25 Channel equalization ..............................................................................28 Error correction and Viterbi decoding ...................................................29 Speech transcoding ................................................................................31 Half-rate and enhanced
  • A Comparison of Two Distributed Systems

    A Comparison of Two Distributed Systems

    A comparison of two distributed systems Finny Varghese Topics Design Philosophies Application environment Processor allocation Design Consequences Kernal Architecture Communication Mechanism File system Process Management 1 Amoeba vs. Sprite 2 philosophical grounds Distributed computing model vs. Unix-style applications Workstation-centered model vs. combination of terminal with a shared processor pool Amoeba vs. Sprite Amoeba Sprite user level IPC RPC model – Kernal use mechanism Caches files only on Client-level caching servers Centralized server – to Process migration model allocate processors 2 Amoeba System Sprite System 3 Design Philosophies 1. How to design a distributed file system with secondary storage shared? 2. How to allow collection of processors to be exploited by individual users Application Environment Amoeba Sprite Process or file = obj Eases – transition from Capability time-sharing to networked Port – hides the server workstations from objects Uniform communication Caching file data – on model workstations Easier - writing distributed application Little or no IPC Orca – programming language 4 Processor Allocation Pure “workstation” – execute tasks on one machine Pure “processor pool” – equal access to all processors Amoeba – closer to processor pool Sprite – closer to workstation model Processor Allocation - Amoeba “pool processor” – network interface and RAM Unlike pure – processors allocation outside pool processors for system services Terminals – only display server 3 reasons for this choice 1. Assumption that processor & memory price decrease 2. Assumption that the cost of adding new processor would be less than adding workstation 3. Entire distributed system – as a time sharing system 5 Processor Allocation - Sprite Priority, processing power of a workstation Unlike pure workstations – uses processing power of idle hosts Dedicated file servers – not for applications 3 reasons for this choice 1.
  • Rlsc & DSP Advanced Microprocessor System Design

    Rlsc & DSP Advanced Microprocessor System Design

    Purdue University Purdue e-Pubs ECE Technical Reports Electrical and Computer Engineering 3-1-1992 RlSC & DSP Advanced Microprocessor System Design; Sample Projects, Fall 1991 John E. Fredine Purdue University, School of Electrical Engineering Dennis L. Goeckel Purdue University, School of Electrical Engineering David G. Meyer Purdue University, School of Electrical Engineering Stuart E. Sailer Purdue University, School of Electrical Engineering Glenn E. Schmottlach Purdue University, School of Electrical Engineering Follow this and additional works at: http://docs.lib.purdue.edu/ecetr Fredine, John E.; Goeckel, Dennis L.; Meyer, David G.; Sailer, Stuart E.; and Schmottlach, Glenn E., "RlSC & DSP Advanced Microprocessor System Design; Sample Projects, Fall 1991" (1992). ECE Technical Reports. Paper 302. http://docs.lib.purdue.edu/ecetr/302 This document has been made available through Purdue e-Pubs, a service of the Purdue University Libraries. Please contact [email protected] for additional information. RISC & DSP Advanced Microprocessor System Design Sample Projects, Fall 1991 John E. Fredine Dennis L. Goeckel David G. Meyer Stuart E. Sailer Glenn E. Schmottlach TR-EE 92- 11 March 1992 School of Electrical Engineering Purdue University West Lafayette, Indiana 47907 RlSC & DSP Advanced Microprocessor System Design Sample Projects, Fall 1991 John E. Fredine Dennis L. Goeckel David G. Meyer Stuart E. Sailer Glenn E. Schrnottlach School of Electrical Engineering Purdue University West Lafayette, Indiana 47907 Table of Contents Abstract ...................................................................................................................
  • Introduction to Digital Signal Processors

    Introduction to Digital Signal Processors

    INTRODUCTION TO Accumulator architecture DIGITAL SIGNAL PROCESSORS Memory-register architecture Prof. Brian L. Evans in collaboration with Niranjan Damera-Venkata and Magesh Valliappan Load-store architecture Embedded Signal Processing Laboratory The University of Texas at Austin Austin, TX 78712-1084 http://anchovy.ece.utexas.edu/ Outline n Signal processing applications n Conventional DSP architecture n Pipelining in DSP processors n RISC vs. DSP processor architectures n TI TMS320C6x VLIW DSP architecture n Signal and image processing applications n Signal processing on general-purpose processors n Conclusion 2 Signal Processing Applications n Low-cost embedded systems 4 Modems, cellular telephones, disk drives, printers n High-throughput applications 4 Halftoning, radar, high-resolution sonar, tomography n PC based multimedia 4 Compression/decompression of audio, graphics, video n Embedded processor requirements 4 Inexpensive with small area and volume 4 Deterministic interrupt service routine latency 4 Low power: ~50 mW (TMS320C5402/20: 0.32 mA/MIP) 3 Conventional DSP Architecture n High data throughput 4 Harvard architecture n Separate data memory/bus and program memory/bus n Three reads and one or two writes per instruction cycle 4 Short deterministic interrupt service routine latency 4 Multiply-accumulate (MAC) in a single instruction cycle 4 Special addressing modes supported in hardware n Modulo addressing for circular buffers (e.g. FIR filters) n Bit-reversed addressing (e.g. fast Fourier transforms) 4Instructions to keep the
  • Simulation and Comparison of Various Scheduling Algorithm for Improving the Interrupt Latency of Real –Time Kernal

    Simulation and Comparison of Various Scheduling Algorithm for Improving the Interrupt Latency of Real –Time Kernal

    Journal of Computer Science and Applications. ISSN 2231-1270 Volume 6, Number 2 (2014), pp. 115-123 © International Research Publication House http://www.irphouse.com Simulation And Comparison of Various Scheduling Algorithm For Improving The Interrupt Latency of Real –Time Kernal 1.Lavanya Dhanesh 2.Dr.P.Murugesan 1.Research Scholar, Sathyabama University, Chennai, India. 2.Professor, S.A. Engineering College, Chennai, India. Email:1. [email protected] Abstract The main objective of the research is to improve the performance of the Real- time Interrupt Latency using Pre-emptive task Scheduling Algorithm. Interrupt Latency provides an important metric in increasing the performance of the Real Time Kernal So far the research has been investigated with respect to real-time latency reduction to improve the task switching as well the performance of the CPU. Based on the literature survey, the pre-emptive task scheduling plays an vital role in increasing the performance of the interrupt latency. A general disadvantage of the non-preemptive discipline is that it introduces additional blocking time in higher priority tasks, so reducing schedulability . If the interrupt latency is increased the task switching delay shall be increasing with respect to each task. Hence most of the research work has been focussed to reduce interrupt latency by many methods. The key area identified is, we cannot control the hardware interrupt delay but we can improve the Interrupt service as quick as possible by reducing the no of preemptions. Based on this idea, so many researches has been involved to optimize the pre-emptive scheduling scheme to reduce the real-time interrupt latency.
  • Get the Inside Track on 27 Years of Microkernel Innovation

    Get the Inside Track on 27 Years of Microkernel Innovation

    Get the inside track on 27 years of microkernel innovation# Sebastien and Colin talked about the history of the QNX Microkernel, the new Hybrid Development Model and then got into some details of how the kernel and the process manager actually work. Archived Web Broadcast# The On-Demand version of the broadcast is available here - http://seminar2.techonline.com/s/qnx_oct1707 Slides# Here are the slides from the webinar - sorry the are in PowerPoint format. Oct27_Microkernel_Innovation/ Webinar_kernel_oct07_final.ppt Questions From The Webinar# There were loads of questions during the webinar! Are there are QNX Kernel development books in process of writing or available now?# Not that I'm aware of - CB Does the Momentics version contain the develoment system and also the OS for the BSP.# What tools one needs to try this out?# is the uK student version FUll or minimal ?# There is only one version - the student and non-commercial aspect is simply the license agreement you select when you download - CB Has or will QNX publish a set of development standards or procedures (e.g., coding conventions)?# Yes - see the developers info page (OSDeveloperInformation) page for our coding guidelines - CB how would the "QNX Comunity" work with the hybrid SW model? how do people out-side of your company contribute?# The OSDeveloperInformation page covers how to contribute - CB could hybrid source model adversely effect stability of customer product ? i.e. enforced product releases for bug fixes....# Our regular releases are still going to be as thoroughly tested as before, there should be no stability problems introduced by sharing our code.
  • History of General-Purpose Operating Systems Unix Opera

    History of General-Purpose Operating Systems Unix Opera

    Software systems and issues Operating system • operating systems • a program that controls the resources of a computer – controlling the computer – interface between hardware and all other software • file systems and databases – examples: Windows 95/98/NT/ME/2000/XP/Vista/7, – storing information Unix/Linux, Mac OS X, Symbian, PalmOS, ... • applications – programs that do things • runs other programs ("applications", your programs) • middleware, platforms • manages information on disk (file system) – where programs meet systems • controls peripheral devices, communicates with outside • interfaces, standards • provides a level of abstraction above the raw hardware – agreements on how to communicate and inter-operate – makes the hardware appear to provide higher-level services than it • open source software really does – freely available software – makes programming much easier • intellectual property – copyrights, patents, licenses What's an operating system? History of general-purpose operating systems • 1950's: signup sheets "Operating system" means the software code that, inter alia, • 1960's: batch operating systems (i) controls the allocation and usage of hardware resources – operators running batches of jobs (such as the microprocessor and various peripheral devices) of – OS/360 (IBM) a Personal Computer, (ii) provides a platform for developing • 1970's: time-sharing applications by exposing functionality to ISVs through APIs, – simultaneous access for multiple users and (iii) supplies a user interface that enables users to access – Unix (Bell Labs; Ken Thompson & Dennis Ritchie) functionality of the operating system and in which they can • 1980's: personal computers, single user systems run applications. – DOS, Windows, MacOS – Unix US District Court for the District of Columbia • 1990's: personal computers, PDA's, … Final Judgment, State of New York, et al v.
  • Course Title

    Course Title

    "Charting the Course ... ... to Your Success!" Linux Internals Course Summary Description This is an intensive course designed to provide an in-depth examination of the Linux kernel architecture including error handling, system calls, memory and process management, filesystem, and peripheral devices. This course includes concept lectures and discussions, demonstrations, and hands-on programming exercises. Objectives At the end of this course, students will be able to: • Identify and understand the components of • Understand and explain error handling; the Linux system and its file system • Understand and explain memory • Boot a Linux system and identify the boot management phases • Understand and explain process • Understand and utilize selected services management • Identify and understand the various • Understand and explain process scheduling components of the Linux kernal • Utilize and change kernal parameters Topics • Introduction • Memory Management • Booting Linux • Process Management • Selected Services • Process Scheduling • The Linux Kernel • Signals • Kernel Parameters • IPC (Interprocess Communication) • Kernel Modules • The Virtual Filesystem • Kernel Error Handling and Monitoring • Interrupts • Kernel Synchronization • Time and Timers • System Calls • Device Drivers Audience This course is designed for Technology Professionals who need to understand, modify, support, and troubleshoot the Linux Operating System. Prerequisites Students should be proficient with basic tools such as vi, emacs, and file utilities. Experience with systems programming in a UNIX or Linux environment is a recommended. Duration Five days Due to the nature of this material, this document refers to numerous hardware and software products by their trade names. References to other companies and their products are for informational purposes only, and all trademarks are the properties of their respective companies.
  • The DENX U-Boot and Linux Guide (DULG) for Canyonlands

    The DENX U-Boot and Linux Guide (DULG) for Canyonlands

    The DENX U-Boot and Linux Guide (DULG) for canyonlands Table of contents: • 1. Abstract • 2. Introduction ♦ 2.1. Copyright ♦ 2.2. Disclaimer ♦ 2.3. Availability ♦ 2.4. Credits ♦ 2.5. Translations ♦ 2.6. Feedback ♦ 2.7. Conventions • 3. Embedded Linux Development Kit ♦ 3.1. ELDK Availability ♦ 3.2. ELDK Getting Help ♦ 3.3. Supported Host Systems ♦ 3.4. Supported Target Architectures ♦ 3.5. Installation ◊ 3.5.1. Product Packaging ◊ 3.5.2. Downloading the ELDK ◊ 3.5.3. Initial Installation ◊ 3.5.4. Installation and Removal of Individual Packages ◊ 3.5.5. Removal of the Entire Installation ♦ 3.6. Working with ELDK ◊ 3.6.1. Switching Between Multiple Installations ♦ 3.7. Mounting Target Components via NFS ♦ 3.8. Rebuilding ELDK Components ◊ 3.8.1. ELDK Source Distribution ◊ 3.8.2. Rebuilding Target Packages ◊ 3.8.3. Rebuilding ELDT Packages ♦ 3.9. ELDK Packages ◊ 3.9.1. List of ELDT Packages ◊ 3.9.2. List of Target Packages ♦ 3.10. Rebuilding the ELDK from Scratch ◊ 3.10.1. ELDK Build Process Overview ◊ 3.10.2. Setting Up ELDK Build Environment ◊ 3.10.3. build.sh Usage ◊ 3.10.4. Format of the cpkgs.lst and tpkgs.lst Files ♦ 3.11. Notes for Solaris 2.x Host Environment • 4. System Setup ♦ 4.1. Serial Console Access ♦ 4.2. Configuring the "cu" command ♦ 4.3. Configuring the "kermit" command ♦ 4.4. Using the "minicom" program ♦ 4.5. Permission Denied Problems ♦ 4.6. Configuration of a TFTP Server ♦ 4.7. Configuration of a BOOTP / DHCP Server ♦ 4.8. Configuring a NFS Server • 5.
  • Improving IPC by Kernel Design

    Improving IPC by Kernel Design

    Improving IPC by Kernel Design Jochen Liedtke German National Research for Computer Science Presented by Emalayan Agenda • Introduction to Micro Kernal • Design Objectives • L3 & Mach Architecture • Design – Architectural Level – Algorithamatic Level – Interface Level – Coding Level • Resutls • Conclusion Micro Kernels • Micro kernels – Microkernel architectures introduce a heavy reliance on IPC, particularly in modular systems – Mach pioneered an approach to highly modular and configurable systems, but had poor IPC performance – Poor performance leads people - The rationale behind its design is to to avoid microkernels entirely, or architect their design to separate mechanism from policy reduce IPC allowing many policy – Paper examines a performance decisions to be made at user level oriented design process and specific optimizations that achieve good performance • Popular Micro kernels - L3 & Mach Design Objectives • IPC performance is the primary objective • Design discussions before implementation • Poor performance replacements • Top to Bottom detailed design (From architecture to coding level) • Consider synergetic effects • Design with concrete basis • Design with concrete performance L3 & Mach Architecture • Similarities - Tasks, threads - Virtual memory subsystem with external pager interface - IPC via messages • L3 - Synchronous IPC via threads • Mach – Asynchronous IPC via ports • Difference - Ports • L3 is used as the workbench Performance Objective • Finding out the best possible case - NULL message transfer using IPC • Goal