Working with OSK5912 Project Phases OMAP Architecture Boot Process Kernel Compilation

Working with OSK5912 Project Phases OMAP Architecture Boot Process Kernel Compilation

Working with OSK5912 Project Phases OMAP Architecture Boot Process Kernel Compilation

Schachtman, Noah, Contributing Editor has reference to this Academic Journal, PHwiki organized this Journal Working with OSK5912 By T Siva Viswanathan Naresh Krishnaswamy Harshvardhan V Project Phases Phase I Introduction to OMAP What is OMAP Open Multimedia Application Plat as long as m Dual Core Processor OMAP5912 ARM926EJS TMS320C55x Exercises Done: Demonstration of Audio Processing Program – Filtering of Voice available from Audio Input using Filters

Keystone College PA

This Particular University is Related to this Particular Journal

OMAP Architecture Phase I Boot Process Studied general boot process Phase I BIOS GRUB/LILO Kernel initrd /sbin/init Run levels Programs Filesystem Kernel Compilation First Exercise – To compile a sample kernel/ filesystem, small enough to fit in a floppy Size Constraint – Severely limited kernel options available Kernel Configured in Linux using make Went as long as minimum possible compilable options – final kernel size around 1 MB Required second floppy as long as file system Phase I

File System Basic File system Problem: Space constraints, not enough resources available on the net. Finding the right configuration/ dependencies in addition to fitting onto a floppy. Phase I NFS – Network File System What is NFS Concept of Server in addition to Client Exports file, NFS Service Network Daemon Mounted Sample Directory from one Computer Using NFS – Direct Connection Using Server Constraint: NETWORK PROBLEM – Inconsistent Network Per as long as mance, NFS server takes unusually long time to initialize Phase I DHCP – Dynamic Host Configuration Protocol Starting DHCP server Dynamic Assignment of IP address to a client from the server Constraints: Network, Configuration of network file Phase I

Additional Work – Bootloader in addition to Filesystem Study Phase I Bootloader U-boot Redboot rrload Filesystems JFFS2 CRAMFS SQUASHFS Working with OSK5912 Components: Bootloader Kernel Filesystem NFS St in addition to alone Filesystem Required as long as starting a proper system. Phase II OSK Kernel Key features: Patching with OMAP patch Configured using make menuconfig NFS option included or St in addition to alone Filesystem – mtdblock support Needed arm specific gcc toolsuite to compile Prb : Root option not included. Kernel did not uncompress Phase II

OSK Filesystem Filesystem populated Files used – Busybox – An introduction Phase II Setting Up the OSK Network Cable Connected Memory pages cleared Boot to Bootloader options menu Phase II Bootloader in system Bootloader options Kernel loaded using Tftpboot to RAM Memory pages cleared Kernel copied to flash from RAM File system loaded via Tftpboot File system copied from RAM to Flash Bootargs changed to mtdblock Bootargs changed to nfs, server ip defined, file specified System Rebooted Filesystem Options Phase II NFS Useful as long as Debugging Quick Change of In as long as mation NFS server required Multiple options can be kept Boot args parameters Fusing Useful as long as Final Product In as long as mation only changed in RAM Limited File size – 16 MB Different Images need to be loaded Size Constraints

Research in filesystems Comparison of JFFS2, Cramfs, Squashfs Failure to implement CRAMFS Phase II Schematics Schematics Analyzed Power management, Flash memory, SDRAM, Audio Codec, Compact Flash, JTAG, USB, Serial Port, Ethernet, Expansion Connectors Possible questions – example Memory Allocation in OSK answered Possible to build a board with required peripherals. Phase III DSP Studied the following: DSP processor fundamentals Harvard Architecture Single Instruction Multiple Data Access ADC input Multi-tasking no parallel processing Direct Memory Access Possible Shift register, MAC, Saturation Arithmetic Circular Buffer DSP processor arch in addition to peripherals DSP Gateway DSP BIOS Phase IV

DSP Processor – TMS320C55x Phase IV Also studied Registers, Memories, Interrupts involved in the Processor DSP Peripherals Phase IV DSP BIOS – The KERNEL Real time kernel on DSP side Real-time scheduling in addition to synchronization Host-to-target communication Real-time instrumentation Phase IV

DSP/BIOS Features Static in addition to Dynamic DSP/BIOS OBJECT Modular APIS Background Idle Loop Minimum Error Checking Phase IV Instrumentation APIs Phase IV Inter processor Communication with DSP Gateway Software enables data transmission between the GPP processor – running Linux – in addition to the DSP. Supports OMAP1510, 1610, 1710, in addition to 5912. Consists of two parts- Linux Device driver on ARM (to be included in kernel while compiling) DSP libraries (compiled in addition to linked into the DSP binaries using Linux-DSP-Tools or CCS Key feature – Usage of DSP TASKS as DEVICE FILES Phase IV

Schachtman, Noah Wired Magazine Contributing Editor

DSP Memory Map INTERNAL MEMORY, 3 types- DARAM SARAM PDROM Mapped onto MPU physical address in addition to MPU virtual space. DSP shadow area Phase IV Communication Done Phase IV Mailbox Mechanism Three mailbox registers- one as long as MPU two as long as DSP Phase IV Communication Done IPBUFS 3 types Global Private System Mailbox protocol Task Ids IPBUFS Ownership is shared. Gets transferred during data transfer.

LINUX API There are five device interfaces DSP task devices- provides interface to DSP tasks as long as Linux applications. Each task is stored as a device file in /dev/dsptasks directory. (Static task, On Dem in addition to Task) DSP task watch device- Find out which task is in use which one has to be loaded etc. DSP control device- Allows the linux application to control the DSP reset read DSP configuration etc. Device file is created at dev/dspctl/ctl. DSP error detection device-used to detect errors such as watchdog timer expiration, DSP MMU error interrupt etc. DSP memory device- Provides access the DSP memory space as long as DSP program loader. Memory capacity can be extended by mapping SDRAM. Phase IV Programming Sending a word from DSP to ARM side Sending Block Private or Public Memory Mapping Task Control Parent Child Common Memory Mapping Frame Buffer Phase IV Sample Program Flow – Word Send Phase IV Arm side DSP side ARM SENDS Word DSP receives word via Word Send Comm in addition to DSP Initialized via dspctl DSP send word via word send comm in addition to Task initialization function called ARM Receives Word

Next step Hope in attempt a simple program involving the CODEC Phase V

Schachtman, Noah Contributing Editor

Schachtman, Noah is from United States and they belong to Wired Magazine and they are from  San Francisco, United States got related to this Particular Journal. and Schachtman, Noah deal with the subjects like Computers; Information Technology Industry

Journal Ratings by Keystone College

This Particular Journal got reviewed and rated by Keystone College and short form of this particular Institution is PA and gave this Journal an Excellent Rating.