Introduction to Embedded Systems

Spring 2014SILICON VALLEY UNIVERSITY

CONFIDENTIAL 1

Introduction to Embedded Systems

Dr. Jerry Shiao, Silicon Valley University

SILICON VALLEY UNIVERSITY CONFIDENTIAL 2

Section 7 Kernel Process / Threads Process Concept Process is a unit of work in a Time-Sharing System. Process contains:

Text Section – Program code. CPU Program Counter CPU Registers Stack – Temporary data ( function parameters, return

addresses, local variables ). Data Section – Global variables. Heap – Dynamically allocated memory during execution.

Copyright @ 2009 John Wiley & Sons Inc.

Stack

Heap

Data

Text

Max

0

Process in Memory

SILICON VALLEY UNIVERSITY CONFIDENTIAL 3Spring 2014

Section 7 Kernel Process / Threads Process Vs Threads

Process Container for an executable object (i.e. an application). The process is a single, sequential, flow of execution. Utilizes system resources, such as memory for data structures, file

descriptors. Kernel uses MMU to protect process from other processes.

Independent processes can be scheduled on other CPUs in a multicore system (parallel execution).

Process can be multithreaded application (i.e. pthread_create() creates multiple threads that can run in parallel, each thread an independent execution flow of the process).

Word editing program is a process and the auto-save and spell check features are separate threads. Process and threads work on same data set (i.e. the document).

Process can be multiprocess application (i.e. fork() creates multiple process that run in parallel).

Copy On Write (COW) delay copying each page in address space until memory is written.

Uses IPC (InterProcess Communication) to communicate with other processes.



POSIX Threads (Partial POSIX Compliant) A process creates threads, which share the same memory

address space, open files, and other resources. Threads exhance the parent process with multiple, parallel

flows of execution within a process. Linux implements threads as standard processes (i.e.

unique task_struct and PID). Threads are scheduled independently by the kernel and

can run on different CPUs for true parallelism. Shared data structures:

Communication between threads can be done through the shared data structures.

POSIX Semaphores or MUTEX used to synchronise thread access.

No protection between threads, one thread can corrupt the memory being used by another thread.

Shared memory has security risks, a compromised thread affects security of other threads.


Section 7 Kernel Process / Threads

Basic unit of CPU utilitzation Thread is flow of control within

process. Multithreaded Process

Thread has: Thread ID. Program Counter. Register Set. Stack.

Shares with other threads: Code Section. Data Section. Operating System

Resources ( files and signals ).


Registers Stack

FilesDataCode

Thread

FilesDataCode

RegistersRegistersRegisters

StackStackStack

Thread



Multitprocess Process Process has:

Thread ID. Program Counter. Register Set. Stack.

Does NOT Shares with other Processes:

Code Section. Data Section. Operating System

Resources ( files and signals ).


Thread

Files

Data

Code

RegistersRegistersRegisters

StackStackStack

Data

Files

Code Code

Files

Data



Multi-Thread Vs Multi-Process Symmetrical Multi-Processor (SMP) environments

supported by Linux. Mainly in server class systems, but now used in

embedded systems. SMP application must exploit parallel execution. Process container for executable object.

Independent sequential flow of execution and separate associated data.

Protected from other processes by Memory Management Unit (MMU).

Kernel can schedule in different CPUs. Threads are parallel flows of execution within a process.

All threads within a process share the same memory space.

Protected from other processes by semaphores. Kernel can schedule in different CPUs.

SILICON VALLEY UNIVERSITY CONFIDENTIAL

8Spring 2014


Multi-Thread Vs Multi-Process Which one to use?

Share resources when executing: Threads Fast communication between executing codes: Threads Control of code executing in parallel: Threads Protection from other executing codes: Process Memory access protection: Process Less complicated (debug): Process Performance context switch: About same

Process when protection (MMU) is important or threads where shared communications (real-time applications) is important.


9Spring 2014


Process Vs Threads Thread-Safe Code

Code executing in thread must call functions that are “thread safe”.

No static or global variables. Use semaphores or mutexes to protect shared

memory. Use caller provided storage (i.e. pointer to variable

or structure) for input data and returned data. Must only call only reentrant (i.e. “thread-safe”)

functions.


10Spring 2014


Process Vs Threads Thread-Safe Code

User caller provided storage for input data and returned data.

/* reentrant function */char *strtoupper_r(char *in_str, char *out_str) { int index;

for (index = 0; in_str[index]; index++) out_str[index] = toupper(in_str[index]); out_str[index] = 0 return out_str;}

/* pseudo-code threadsafe function */int increment_counter();{ static int counter = 0; static lock_type counter_lock =

LOCK_INITIALIZER; pthread_mutex_lock(counter_lock); counter++; pthread_mutex_unlock(counter_lock); return counter;}

Use semaphores or mutexes to protect shared memory.



Linux Threading: clone() fork(): process

CLONE_CHILD_CLEARTID: erase child thread ID when child exits.

CLONE_CHILD_SETTID: store child thread ID. SIGCHLD: Termination signal sent to parent when child dies.

pthread_create(): thread CLONE_FILES: share the same file descriptor table. CLONE_VM: share the same memory space. CLONE_FS: share file system information CLONE_SIGHAND: share same table of signal handlers. CLONE_THREAD: share the same thread group as the calling

process. CLONE_SYSVSEM: share a single list of System V semaphores. CLOSE_SETTLS: Set Thread Local Storage descriptor. CLONE_PARENT_SETTID: store child thread ID. CLONE_CHILD_CLEARTID: erase child thread ID when child

exits.



Native POSIX Thread Library (NPTL) Fully POSIX compliant. Improved performance. M:N threading model.

PThread is 1:1 model. Kernel identification of threads to single Process ID (PID). Signal handling performed for the process.

PThreads has PID for each Thread. Signaling handling sent to Thread, not to process as a whole.

Resource usage associated with single PID. PThreads resource display, showed shared memory for

PThreads as separate memory for thread. Overhead of thread exiting was reduced. NPTL threads are reentrant. NPTL and PThread support POSIX APIs. No migration

necessary from PThread to NPTL.



Process Vs Threadsint main()

{

…

pid_t pID = fork();

If (pID == 0) {

sIdent = “Child Process: “;

…

} else if (pID < 0) {

/* Failed to fork. */

exit(1);

} else {

sident = “Parent Process:”;

}

…

}

fork:

Spawn a new child process which is an identical process to the parent, except that it has a new system process ID. The process is copied in memory from the parent.

- Copy-on-write memory pages created.

- Duplicate parent’s page tables.

- Create unique task_struct for the child.

- Return value = 0 indicates child’s process.

child PID in the parent’s process.

-1 error, no child process created.



Process Vs Threadsint func1()

{

/* Thread function. */

…

}

int main()

{

…

iret1 = pthread_create(

&tid1, NULL, func1,

(void *)message1);

…

pthread_join( tid1, NULL);

…

return 0;

}

pthread_create:

Creates a new thread with attributes in the call or NULL for default attributes.

- tid1 recieves the thread ID.

- NULL uses the default thread attributes.

- func1 is the pointer to the function to be threaded.

- message1 is the pointer to the argument.

pthread_join:

Waits for termination of another thread.

- tid1 is the thread the main process is waiting to

terminate.

NULL specifies return value not needed.


Section 7 Kernel Process / Threads Assignment 5: Kernel Module

make Utility (/usr/bin/make) automates the building of software based on

specification of dependencies among files. Object files depend upon program source files.

Generates a sequence of commands for execution by the Linux shell.

Keep track of list of files or objects that required other files to be current before they can be rebuilt.

Each statement is a rule. Each rule has target(s), file(s) to be generated, and files they

depend upon (prerequisites or dependencies). Makefile, makefile, GNUmakefile default file containing all the rules. Options:

make –f <makefile> : Alternate file containing rules. make –C<dir> : cd to <dir> before reading Makefile make –d : Enable debugging.



make Makefile Lines

No tab precede targets. Tab precedes a command.

Dependency: targets : prerequisites

prog.o: foo.h $(CC) -c $(CFLAGS) prog.o

Macro: name:=value

bar = v1 foo := $(bar) foo is assigned 'v1'

Text Manipulation Functions: $(patsubst pattern , replacement , text )

OBJS := ${patsubst %.c, %.o, ${wildcard *.c}}



Program Functions int open(char * filename, int flags)

flags = bitwise | or of operations permitted: O_RDWR Read and Write operations both permitted

returns <0 for error, or integer file descriptor. Example: fd = open("/proc/assignment5", O_RDWR);

int read(int fd, void * ptr, int numbytes) fd = file descriptor as returned by open ptr = address in memory where data is to be stored; numbytes = number of bytes to attempt to read returns <0 for error, 0 for end-of-file, or number of bytes successfully

read. Example: rc = read(fd, rd_buf, 4);

int close(int fd) fd = file descriptor as returned by open returns <0 for error, 0 for success.



Kernel Module Functions #include <linux/jiffies.h>

Contains extern for global variable, jiffies. Jiffies represents the number of timer ticks since CPU was started.

#include <linux/proc_fs.h> Needed when using procfs functions.

struct proc_dir_entry* create_proc_entry(const char* name, mode_t mode,

struct proc_dir_entry* parent); name = file name. mode = file permissions. parent = directory to create the file. NULL = root of /PROC filesystem. Example: Our_Proc_File = create_proc_entry(PROCFS_NAME, 0644,

NULL); module_init( x )

Macro used to register the name (x) of the module initialization function. module_exit( x )

Macro used to register the name (x) of the module cleanup code.


Section 8 Linux Interrupt Handlers Types Of Interrupt Handlers

Interrupt is an event that alters the sequence of instructions executed by a processor.

Synchronous interrupts (exceptions) produced by CPU. Programming errors, divide by zero, illegal memory ref. Conditions handled by kernel, page fault. System calls.

Asynchronous interrupts generated by hardware devices. Keyboard keystrokes. Data received.

Interrupt and exception handlers are not processes, they execute in kernel control path.

Interrupt handler executes critical code with interrupts disabled. Defers as much processing as possible.

Minimize latency minimizes duration interrupts are disabled.


Section 8 Linux Interrupt Handlers

Hardware Interrupts

Ethernet

Controller

I/O Controller

SCSI Disk

Real-Time Clock

I/O

Advanced

Programmable

Interrupt

Controller

(APIC)

Interrupt ReQuest Lines

(IRQ)

Local APIC

Local APIC CPU 1

CPU 0

Inte

rrup

t C

ontr

olle

r C

omm

unic

atio

n (I

CC

) B

usI/O devices: Unique or shared Interrupt ReQuest Lines (IRQs).

I/O APIC: 24 IRQ lines. Send/Receive APIC Messages over ICC BUS to Local APICs.

IRQ signals delived to available CPUs (Static or Dynamic Distribution)

Local APIC: Mapped to interrupt vectors.

Signals processor with INTR (issues an interrupt).

INTR

INTR



Programmable Interrupt Controller Functionality Responsible for raising interrupt signal to the CPU

when an external device sends IRQ. Monitors the IRQ lines.

Controller translates IRQ to vector. IRQ line 0 Vector 32

IRQn Vector n + 32 Raises interrupt to CPU. Places vector in register allowing CPU to read. Waits for ACK from CPU. When ACK received, controller

goes back to monitoring IRQ lines.

Controller prioritize multiple IRQs. Controller can mask (disable) IRQs.



Programmable Interrupt Controller Functionality

PIC

IRQs

. . .CPU

idtr

vector

IDT

Gate Descriptor

(Interrupt Handler)

0

255

INTR

Mask points


PIC

IRQs

. . .

INTR

Mask points


o IRQ assignment is hardware dependent, fixed by architecture.

o Linux device driver request IRQ when the device is opened.

o Two devices that are not used at the same time can share IRQ.

1) Monitors IEQ lines. If two or more IRQs are raised, selects the one having the lower pin number.

2) Raised signal occurs at IRQ line, deliver the IRQ to the local APIC.

3) APIC converts the raised signal into interrupt vector.

4) Stores the interrupt vector in controller I/O port, allowing CPU to read it via data bus.

5) Sends raised signal to the CPU INTR pin (issues an interrupt).

6) CPU reads interrupt vector and indexes into the IDT, containing ISRs for the interrupt.

7) PIC waits until CPU acknowledges the interrupt.

8) PIC monitors the IRQ line again.


Section 8 Linux Interrupt HandlersInterrupt Descriptor Table (IDT)

Interrupt Descriptor Table

0

. . .

19

20

. . .

31

32

. . .

127

128

129

. . .

238

Intel Reserved

External Interrupts

( IRQs )

External Interrupts

( IRQs )

Nonmaskable Interrupts

Exceptions

System Call

SegmentOffset DPL Trap Gate Descriptor

SegmentOffset DPL Interrupt Gate Descriptor

SegmentOffset DPL

SegmentOffset DPL

Interrupt Gate DescriptorInterrupt Gate Descriptor

Interrupt / Exception Vectors



Exception Handler Two types: CPU-detected exceptions (i.e. error conditions) and

programmed exceptions. Linux provides a dedicated exception handler for each exception type. CPU-detected: Aborts (Serious/Hardware Failure), Traps (Debugger),

Fault (Correctable, program restarts).

Exception Vector Exception Handler Exception Type

- (0) Divide Error

- (16) Floating-point Err

divide_error()

coprocessor_error()

Processor: Aborts

- (1) Debug debug() Processor: Traps (Debug Registers)

- (14) Page Fault page_fault() Processor: Fault

- (3) Breakpoint

- (128) System Call

int3()

int()

Programmed Exception (Trap)



Interrupt Handlers (IRQ) Classes Of Interrupts

I/O Interrupts: Interrupt handler queries device to determine proper course of action.

Timer Interrupts: Fixed-time interval has elapsed. Used in time sharing technique for Linux scheduling.

Interprocessor Interrupts: CPU-CPU interprocess interrupt.

IRQ Interrupt Vector Hardware Device

0 32 Timer

1 33 Keyboard

10 42 Network Interface

12 44 Mouse


Section 8 Linux Interrupt Handlers I/O Interrupt Handlers

I/O Interrupt Handler service multiple devices ( device share same IRQ).

Executes multiple Interrupt Service Routines (ISRs), since Interrupt Handler is not aware of which device generate IRQ.

Actions to be performed in Interrupt Handler: Critical: Must be executed immediately with maskable

interrupts disabled. Acknowledge interrupt to the Prog Interrupt Controller.

NonCritical: Must be executed immediately, but maskable interrupts are enabled.

Updating data structures accessible by processor. Reading bar code after keyboard key pushed.

NonCritical Deferrable: Delayed without affecting kernel operations ( Softirqs and Tasklets).

Copying I/O buffer’s contents to address space of process. Sending keyboard line buffer to terminal handler process.



Handling I/O Interrupts HardwareDevice 1 Device 2

Programmable

Interrupt Controller

(PIC)

IDT [ 32 + n ]

interrupt [ n ]

do_IRQ( n )

Interrupt Service Routine 1

Interrupt Service Routine 1

Software(Interrupt Handler)

I/O Interrupt Handler Actions:1. Save the IRQ and register contents in Kernel Mode Stack.

2. Send acknowledgment to PIC servicing the IRQ line, thus

allowing PIC to issue further interrupts.

3. Execute the Interrupt Service Routines (ISRs) associated

with all devices that share the IRQ.

4. Terminate and return to interrupted process in Kernel

Mode Stack.

IRQ



Interrupt VectorsVector Range Use

0-19 (0x0 – 0x13) Nonmaskable interrupts and exceptions

20-31 (0x14 – 0x1f) Intel-reserved

32-127 (0x20 – 0x7f) External interrupts (IRQs)

128 (0x80) Programmed exception for system calls.

129-238 (0x81 – 0xee) External interrupts (IRQs)

239 (0xef) Local APIC timer interrupts.

240 (0xf0) Local APIC termail interrupt function

241-250 (0xf1 – 0xfa) Reserved by Linux for future use.

251 – 253 (0xfb - -0xfd) Interprocess interrupts

254 (0xfe) Local APIC error interrupts

255 (0xff) Local APIC spurious interrupt

IRQ INT Hardware Device

0 32 Timer

1 33 Keyboard

2 34 PIC cascading

3 35 Second serial port

4 36 First serial port

6 38 Floppy Disk

8 40 System clock

10 42 Network interface

11 43 USB port, sd card

…

IRQ Exception

0 Divide error

1 Debug

2 NMI

3 Breakpoint

4 Overflow

5 Bounds check

6 Invalid opcode

7 Device not available

8 Double fault

9 Coprocessor overrun

10 Invalid TSS

11 Segment not present

…


Section 8 Linux Interrupt Handlers Interrupt Handlers

Hardware Interrupts (Hard IRQs) Interrupt context: Kernel is executing an interrupt handler

or a deferrable function. Interrupt context cannot sleep or block, not associated with

a process. Interrupt handler disables interrupts.

Handler must be quick, only time-sensitive operations: Just acknowledges Programmable Interrupt Controller. Reset device register. Copying data from device into main memory.

Handler must not block interrupts for long periods (no other interrupts can be received until current interrupt handler terminates.).

Remove deferrable actions from interrupt handler. Allows interrupt to quickly complete and keeps kernel

response time short (i.e. serviced in few milliseconds). Allows other interrupts to be enabled.



Softirqs and Tasklets Handle actions of the interrupt handler that are

not time critical, can be deferred. Execute with interrupts enabled. Non-urgent interruptible kernel functions.

Softirqs statically allocated (defined at compile time).

Reentrant, run concurrently on multiple CPUS.Tasklets implemented on top of softirqs and

dynamically allocated at runtime. Tasklets not reentrant (serialized). Same type of Tasklets

cannot execute on different CPUS. Tasklets preferred implementation for I/O Drivers.



Hardware Interrupts, Softirqs,Tasklets, and Workqueues

CPU

User Process

Interrupt HandlerTop Half

BottomHalf

IRQ

Interrupt Context

Kernel Context

Softirq

Softirq / Tasklet

Events Kernel Thread

BottomHalf

Workqueue

Work FunctionWork

FunctionWork Function

Scheduler

Ksoftirqd Kernel Thread

Bottom Half

User Context Kernel Context Kernel Context



Interrupt Handlers Softirqs Specifics

Kernel uses Softirqs: After system calls. After exceptions. After interrupts (top halves/IRQs, timer). Scheduler runs ksoftirqd (kernel thread).

High volume of Softirqs/Tasklets. Softirqs/Tasklets scheduled with user processes.

Softirq routines can be executed simultaneously (supports SMP).

Softirq code must be re-entrant. Code must do its own locking.

Hardware interrupts always enabled when softirqs are running.


Section 8 Linux Interrupt Handlers Interrupt Handlers (Softirqs/Tasklets)

Interrupt Service

Routine

----------------------

open_softirq()

raise_softirq()

wakeup_softirq()

----------------------

tasklet_init()

tasklet_enable()

tasklet_schedule()

tasklet_hi_schedule()

06

54

32

1

Irq_cpubits_t

softirq_vec

0 HI_SOFTIRQ

1 TIMER_SOFTIRQ

2 NET_TX_SOFTIRQ

3 NET_RX_SOFTIRQ

4 SCSI_SOFTIRQ

5 TASKLET_SOFTIRQ

. . .

31

Scheduler

tasklet_hi_vec

next

state

count

func

data

tasklet_descriptor

<tasklet_func()>

<data>

action

data

softirq_action

<softirq_func()>

<data>

tasklet_hi_vec

next

state

count

func

data

tasklet_descriptor

<tasklet_func()>

<data>



Interrupt HandlersWorkqueues

Workqueue function executed by kernel thread (runs in process context).

Softirq and tasklets run in interrupt context. Workqueue function can sleep or block, invoke

the scheduler. Only option for device drivers that need to sleep or

block. Manage semaphores.

Kernel thread: Workqueue default kernel thread per CPU. Invoke kernel thread for your workqueue.


Section 8 Linux Interrupt Handlers Interrupt Handlers (Workqueue)

Interrupt Service

Routine

-------------------------------

create_workqueue()

queue_work()

queue_delayed_work()

flush_workqueue()

Scheduler

<work_func()>

<data>

. . .

worklist

more_work

work_done

thread

run_depth

workqueue_struct

. . .

entry

func

data

work_struct

. . .

entry

func

data

work_struct

<work_func()>

<data>

Worker thread:

Process descriptor pointer



Interrupt HandlersWorkqueues

1) Worker thread.2) Multiple types of worker

threads, but usually the default event thread is used.

3) Each type of worker thread, one thread per processor.

1) Work.2) The driver creates work, which

needs to be deferred to later.3) work_struct represents work . Work

is a pointer to the function that will handle the deferred work.



Interrupt HandlersKernel Threads Reduce latency, interrupts disabled minimized.

Quick Check Handler: ensures interrupt is from supported device.

Acknowledge the interrupt and wake interrupt handler thread.

Reduce complexity, simplifying “hard” and “soft” parts of interrupt handler.

Simplify locking issues in concurrent memory access. request_threaded_irq() requests kernel thread for interrupt

handler. Unlike softirqs or tasklet, bottom half has its own context.

Scheduled with other processes.



Interrupt Handler

Softirqs Tasklet Work

Queues

Kernel

ThreadsContext Interrupt Interrupt Process Process

Executes in sequence (nonReentrant)

Run simultaneously on different CPUS.

More than one run on same CPU.

Block or go to sleep.

Full context switch.

Higher priority.

ksoftirqd ksoftirqd

Date post:	14-Jan-2016
Category:	Documents
Upload:	rona
View:	27 times
Download:	0 times

Introduction to Embedded Systems

Documents