Transcript Working with OSK5912 - USC Robotics Research Lab

Working with OSK5912
By T Siva Viswanathan Naresh Krishnaswamy Harshvardhan V
Project Phases
Codec
DSP Gateway
Schematic Analysis
Booting From OSK5912
Preparation to Work with Kit
Phase I
Introduction to OMAP
ARM926EJS
What is OMAP?
Open Multimedia
Application Platform
Dual Core Processor
OMAP5912
TMS320C55x
Exercises Done:
Demonstration of Audio Processing
Program – Filtering of Voice available
from Audio Input using Filters
Phase I
OMAP Architecture
Phase I
Boot Process
• Studied general boot process
BIOS
Filesystem
Run levels
GRUB/
LILO
Kernel
/sbin/init
initrd
Programs
Phase I
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 for minimum possible compilable
options – final kernel size around 1 MB
• Required second floppy for file system
Phase I
File System
• Basic File system
• Problem: Space constraints, not enough resources available on the
net. Finding the right configuration/ dependencies and fitting onto a
floppy.
File
system
/dev
/usr
/sbin
/bin
/etc
/lib
/mnt
/opt
/proc
/root
/tmp
Phase I
NFS – Network File System
• What is NFS? Concept of
Server and Client
• Exports file, NFS Service
• Network Daemon
• Mounted Sample Directory
from one Computer Using
NFS – Direct Connection
Using Server
• Constraint: NETWORK
PROBLEM – Inconsistent
Network Performance, 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 and
Filesystem Study
Filesystems
Bootloader
SQUASHFS
rrload
Redboot
CRAMFS
JFFS2
U-boot
Phase II
Working with OSK5912
• Components:
– Bootloader
– Kernel
– Filesystem
• NFS
• Standalone Filesystem
Required for starting a proper system.
Phase II
OSK Kernel
• Key features:
– Patching with OMAP patch
– Configured using make menuconfig
• NFS option included or
• Standalone 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 –
File
system
/dev
/usr
/Bin
/sbin
/bin
/etc
/sbin
• Busybox – An introduction
/lib
/mnt
/opt
/proc
Phase II
Setting Up the OSK
Bootloader
in system
Boot to
Bootloader
options menu
File system copied
from RAM to Flash
Bootargs changed
to mtdblock
Memory
pages
cleared
Bootloader
options
Kernel loaded
using Tftpboot to
RAM
Memory
pages
cleared
File system loaded
via Tftpboot
Kernel copied to
flash from RAM
Bootargs changed
to nfs, server ip
defined, file
specified
System
Rebooted
Network
Cable
Connected
Phase II
Filesystem Options
NFS
Fusing
•Useful for Debugging
•Useful for Final Product
•Quick Change of
Information
•Information only changed
in RAM
•NFS server required
•Limited File size – 16 MB
•Multiple options can be
kept
•Different Images need to
be loaded
•Boot args parameters
•Size Constraints
Phase II
Research in filesystems
• Comparison of JFFS2, Cramfs, Squashfs
• Failure to implement CRAMFS
JFFS2
CRAMFS
SQUASHFS
YAFFS
RAMFS
R/W
Read-only
Read-only
R/W
R/W
RAM Usage
No
Yes
Yes
Yes
Yes
Size on disk
Loop Back
Fixed
Fixed
Variable
Variable
Yes
Yes
Yes
Yes
N/A
only 1 : 1
only 2 : 1
1: 1 or 2 : 1
only 1 : 1
only 1 : 1
Logic
NOR
NOR
NOR
NAND
RAM
Block Size
64 K
4K
4 K - 64 K
16 K
64 K - 256 K
MTD Driver
Make cramfs
mksquashfs
MTD Driver
MTD Driver
Usage
Compression support
Compression Ratio
Creating utility
Phase III
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 IV
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 and peripherals
– DSP Gateway
– DSP BIOS
Phase IV
DSP Processor – TMS320C55x
Also studied Registers, Memories, Interrupts involved in the Processor
Phase IV
DSP Peripherals
ADC
Timer
DMA
Controller
Clock
Generator
USB
WD
Timer
GPIO
Core
External
Memory
Interface
RTC
Enhanced Host
Port Interface
I2C Module
McBsP
MMC
Phase IV
DSP BIOS – The KERNEL
•
•
•
•
Real time kernel on DSP side
Real-time scheduling and synchronization
Host-to-target communication
Real-time instrumentation
Phase IV
DSP/BIOS Features
Static and
Dynamic
Background
Idle Loop
DSP/BIOS
OBJECT
Modular APIS
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 - and the
DSP.
• Supports OMAP1510, 1610, 1710, and 5912.
• Consists of two parts– Linux Device driver on ARM (to be included in kernel
while compiling)
– DSP libraries (compiled and linked into the DSP
binaries using Linux-DSP-Tools or CCS
• Key feature – Usage of DSP TASKS as DEVICE
FILES
Phase IV
DSP Memory Map
• INTERNAL MEMORY, 3 types– DARAM
– SARAM
– PDROM
• Mapped onto MPU physical address and MPU virtual
space.
• DSP shadow area
Phase IV
Communication Done
Mailbox Mechanism
Three mailbox registers- one for MPU two for DSP
Phase IV
Communication Done
IPBUFS
3 types
•Global
•Private
•System
Mailbox protocol
•Task Ids
•IPBUFS
•Ownership is shared. Gets transferred during data
transfer.
Phase IV
LINUX API
• There are five device interfaces
• DSP task devices- provides interface to DSP tasks for
Linux applications. Each task is stored as a device file in
/dev/dsptasks directory. (Static task, On Demand 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 for 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
Arm side
DSP side
DSP Initialized via
dspctl
Task initialization
function called
ARM SENDS Word
ARM Receives Word
DSP receives word via
Word Send Command
DSP send word via
word send command
Phase IV
Own Programs Tried
•
•
•
•
Word Send
Addition Program
Multiplication Program
PRD Module – TCF Editing
Phase IV
TCF Text Configuration File
•
•
•
•
•
Module Based Approach
Modules Available
Types of Settings – Global, Local
Analysis of Files which are called.
Creation of custom functions that can use
these files
Phase V
Codec – Current Stage
• AIC23 – Codec to be used with DSP
• Studied Registers, Configuration of Codec and
link via DSP side
• Attempting various modes of communication
Phase V
Framework
Phase V
Method 1
• Codec Accessed via
DSP
• Need to configure .tcf
file to include adaptor
and initialize the
Lower Level Drivers
• Attempt to adapt a
similar approach to
DSP BiosLink
ARM
DSP
CODEC
Phase V
Method 2
• Directly accessing
CODEC via ARM
using ioctl commands
• Create two tasks and
let ARM interface
between the two
CODEC
ARM
DSP
Phase V
Next step
• Hope in attempt a simple program
involving the CODEC