Transcript PPT

ECE 412:
Microcomputer Laboratory
Lecture 6: Making Hardware Talk to Software
Lecture 6
1
Review Questions
• What are the major components in a Linux Execution
Environment?
• What is preemptive multitasking?
• What are the major functionalities offered by the
system kernel? (list a few that you can remember).
Lecture 6
2
Review Questions
• What are the major components in a Linux Execution
Environment?
– Program, libraries, kernel subsystems.
• What is preemptive multitasking?
– The ability of the operating system to preempt or stop a
currently scheduled task in favour of a higher priority task.
• What are the major functionalities offered by the
system kernel? (list a few that you can remember).
– System calls offer general purpose services
– Controls and mediates access to hardware
– Implements and supports fundamental abstractions:
• Process, file system, devices, interprocess communication
– Schedules / allocates system resources:
• CPU, memory, disk, devices, etc.
– Enforces security and protection
Lecture 6
3
Outline
• Hardware/software interface
• Interrupt handling
Lecture 6
4
Hardware/Software Co-design
• Many reasons why we want hardware devices to
interact with software programs
– Input: keyboards, mice, scanners
– Output: CRT, printer
– Interact with real world: contact sensor, chemical analyzer,
MEMS devices
– Performance: ASIC/System-on-chip designs
• Many applications require more compute power, compute-perdollar, or compute-per-watt than microprocessors can deliver
• Exploit 90-10 rule of software by implementing critical parts of
application in HW, non-critical as SW
– Issue: embedded apps getting more complex, less likely to have one
module that consumes most of the execution time.
Lecture 6
5
Hardware-Software Interfaces
• What features do we want?
– Some way to get data between HW and SW components
– Some way for HW to notify SW of asynchronous events
– Flexibility
• Don’t want to have to have special HW in CPU for each device
• Only load SW into memory for devices that are present
– Bandwidth
• Demands may vary wildly: compare keyboard to Gb Ethernet
– Security:
• Multiple users/processes may need to share HW
Lecture 6
6
Getting Data to/from CPU: Hardware Side
I/O Device
I/O Device
Processor
Naïve Direct
connection
I/O Device
I/O Device
I/O Device
CS
I/O Device
CS
Processor
I/O Device
I/O Bus
Lecture 6
7
The Software Side: Memory-Mapped I/O
mmap()
call
Operating
System
Address
Space
Lecture 6
I/O Device
Memory
and Control
Registers
8
Memory-Mapped I/O
• Basic Idea – Make control registers and I/O device
memory appear to be part of the system’s main
memory
– Reads and writes to that region of the memory are translated
by OS/hardware into accesses of hardware device
– Makes it easy to support variable numbers/types of devices
– just map them onto different regions of memory
• Managing new devices is now like memory allocation
• Example: accessing memory on a PCMCIA card
– Once card memory mapped into address space, just hand out pointers like
conventional memory
– Accessing I/O device registers and memory can be done by
accessing data structures via the device pointers
• Most device drivers are now written in C. Memory mapped I/O
makes it possible without special changes to the compiler
Lecture 6
9
Memory-Mapped I/O (cont’)
• Important abstraction
– A given processor may have multiple busses/connections to
devices
• Ex: PPC in Virtex-II Pro has OCM bus to talk to BlockRAM,
PLB bus to talk to other hardware, but they look the same once
you call mmap()
• Can interact a bit oddly with caches
– References to memory-mapped addresses may not go to the
right bus if the address is cached
– Solution: declare any data structures that are memorymapped I/O regions as volatile
• Ex: volatile int *region;
• Tells system that it can’t keep the address in the cache
Lecture 6
10
IBM CoreConnect used by Xilinx
Lecture 6
11
Three Different Buses
•
The PLB on-chip bus is used in highly integrated systems. It supports
read and write data transfers between master and slave devices
equipped with a PLB interface and connected through PLB signals.
•
Lower-performance peripherals are attached on the on-chip peripheral
bus (OPB). A bridge is provided between the PLB and OPB to enable
data transfer by PLB masters to and from OPB slaves.
•
The device control register (DCR) bus is used primarily for accessing
status and control registers within the various PLB and OPB masters and
slaves. It is meant to off-load the PLB from the lower-performance status
and control read and write transfers
Lecture 6
12
Handling Asynchronous Events
• Issue: External devices operate on different time
signals than processor
– Humans don’t have clock rates
• Want:
– Way to let processor handle events on external hardware
that it can’t predict
– Processor to be able to do other things while it’s waiting for
an event
– Fast response to events
– Low overhead (few wasted CPU cycles when no event
happens)
Lecture 6
13
Alternative 1: Polling
• Every so often, processor checks each device to see
if it has a request
– Takes CPU time even if no requests pending
– Tradeoff between overhead and average response time
– How does software know when to let the system poll?
Lecture 6
14
Alternative 2: Interrupts
• Give each device a wire (interrupt line) that it can use
to signal the processor
– When interrupt signaled, processor executes a routine called
an interrupt handler to deal with the interrupt
– No overhead when no requests pending
Device
Processor
Interrupt
Controller
Device
Device
Device
Lecture 6
15
So, What Happens When an Interrupt Occurs?
Acts a lot like a context switch.
• Interrupt controller signals processor that interrupt has occurred,
passes interrupt number
• Processor uses interrupt number to determine which handler to
start
– interrupt vector associates handlers with interrupts
• Processor halts current program
– Multi-cycle operations may be halted or squashed and restarted
– This is a problem on architectures (like some VLIWs) that count on
knowing exactly how long an instruction takes.
• Current program state saved (like context switch)
• Processor jumps to interrupt handler
• When interrupt done, program state reloaded and program
resumes
• Interrupts are assigned priorities to handle simultaneous
interrupts
Lecture 6
16
Interrupt-driven I/O using vectored interrupt (a
carton)
Program memory
1(a): P is executing its main
program
1(b): P1 receives input data in
a register with address 0x8000.
ISR
16: MOV R0, 0x8000
17: # modifies R0
18: MOV 0x8001, R0
19: RETI # ISR return
...
Main program
...
100: instruction
101: instruction
Lecture 6
μP
Data memory
System bus
Inta
Int
PC
100
P1
P2
16
0x8000
0x8001
17
Interrupt-driven I/O using vectored interrupt
(cont’)
2: P1 asserts Int to request
servicing by the microprocessor
Program memory
ISR
16: MOV R0, 0x8000
17: # modifies R0
18: MOV 0x8001, R0
19: RETI # ISR return
...
Main program
...
100: instruction
101: instruction
Lecture 6
μP
Data memory
System bus
Inta
Int
PC
100
P1
1
P2
16
0x8000
0x8001
18
Interrupt-driven I/O using vectored interrupt
(cont’)
Program memory
3: After completing instruction at
100, μP sees Int asserted, saves
the PC’s value of 100, and asserts
Inta
ISR
16: MOV R0, 0x8000
17: # modifies R0
18: MOV 0x8001, R0
19: RETI # ISR return
...
Main program
...
100: instruction
101: instruction
Lecture 6
μP
Data memory
System bus
Inta
Int
PC
100
1
P1
P2
16
0x8000
0x8001
19
Interrupt-driven I/O using vectored interrupt
(cont’)
Program memory
4: P1 detects Inta and puts interrupt
address vector 16 on the data bus
ISR
16: MOV R0, 0x8000
17: # modifies R0
18: MOV 0x8001, R0
19: RETI # ISR return
...
Main program
...
100: instruction
101: instruction
Lecture 6
μP
Data memory
System bus
16
Inta
Int
PC
100
P1
P2
16
0x8000
0x8001
20
Interrupt-driven I/O using vectored interrupt
(cont’)
Program memory
5(a): PC jumps to the address on
the bus (16). The ISR there
reads data from 0x8000,
modifies the data, and writes the
resulting data to 0x8001.
5(b): After being read, P1
deasserts Int.
ISR
16: MOV R0, 0x8000
17: # modifies R0
18: MOV 0x8001, R0
19: RETI # ISR return
...
Main program
...
100: instruction
101: instruction
Lecture 6
μP
Data memory
System bus
Inta
Int
PC
100
P1
0
P2
16
0x8000
0x8001
21
Interrupt-driven I/O using vectored interrupt
(cont’)
Program memory
6: The ISR returns, thus restoring
the PC to 100+1=101, where the
μP resumes
ISR
16: MOV R0, 0x8000
17: # modifies R0
18: MOV 0x8001, R0
19: RETI # ISR return
...
Main program
...
100: instruction
101: instruction
Lecture 6
μP
Data memory
System bus
Int
PC
100
+1
P1
P2
0x8000
0x8001
22
Example: Interrupts on 80386EX
• 80386 core has one interrupt line, one interrupt
acknowledge line
• Interrupt sequence:
– Interrupt controller raises INT line
– 80386 core pulses INTA line low, allowing INT to go low
– 80386 core pulses INTA line low again, signaling controller to
put interrupt number on data bus
INT:
INTA:
Data bus:
Interrupt #
Lecture 6
23
Using Interrupts in Linux
•
OS handles interaction with interrupt hardware
– Necessary to support multiple processor types
•
You need to worry about three things
1. Writing the interrupt handler
2. Registering the interrupt handler with the OS
•
Tells the OS that it should run the handler when the interrupt
occurs
3. Interaction between the interrupt handler and user
programs
•
•
Handlers need to be run in very little time
Handlers run as part of the operating system
– Linux doesn’t allow them to access user data
•
Our general approach: User program does the work, interrupt
handler just signals it when it’s time to do something
Lecture 6
24
Interrupts in Linux
• Documentation on interrupts, etc. in Linux:
http://www.xml.com/ldd/chapter/book/index.html
– Entire Linux Device Drivers book by Rubini and Corbet
is available via the web, free distribution license
– Key chapters for this stuff: Chapter 5 (Blocking I/O) and
Chapter 9 (Interrupts)
– Copies of the book are placed in the lab
Lecture 6
25
Writing an Interrupt Handler
• An interrupt handler is just a C procedure
– void int_handler(int irq, void *dev_id,
struct pt_regs *regs)
– Must match this declaration
• Limits what data you can pass in to the handler
– Can’t return any value
• No calling procedure to return value to
• Interrupt handlers have significant limits on what they
can do
– Can’t directly read or write data in user space (not
associated with a process)
– Can’t do anything involving scheduling new threads or
sleeping
– Need to terminate quickly to free up interrupt hardware
Lecture 6
26
Interrupt Handlers
Most interrupt handlers follow a similar format:
1. Read/write data to/from the device that signaled the
interrupt
•
Ex: get character typed on a keyboard
2. Signal any processes that are waiting for the device
to complete its operation
3. Signal the device that the interrupt has been
handled
•
Often called “clearing the interrupt”
Lecture 6
27
Communicating With User Programs
• Problem: interrupts can’t directly read/write data in a
user program’s space
FPGA
PowerPC
Interrupt
Handler
Frame
Displayer
Interrupt
Frame
Grabber
Video Frame
Lecture 6
28
Two Approaches
1. Interrupt handler copies data from interrupting
device, places it into a buffer that is mapped onto a
/dev/foo entry that user program can then read
•
•
Illustrated in book
Not the approach we recommend – buffer size/overrun
issues
2. User program handles actual reading/writing of data
to/from device.
•
•
•
User program sleeps after each data transfer
All the interrupt handler does is to wake the user program
up whenever the device is ready
In this approach, the user program, not the interrupt
handler, should clear the interrupt bit on the device, to
prevent the device from overwriting data before the user
program has read it.
Lecture 6
29
Example: Frame Grabber/Displayer
• Frame Display code:
While(1) {
interruptible_sleep_on(&queue); /* sleep until interrupted */
(Do PCMCIA reads to grab frame of data from XUP)
(Do PCMCIA write that tells XUP that interrupt has been
processed)
(Do frame data munging and display)
}
• See chapter 5 in device driver book for details of how
queue variable is declared and used
Lecture 6
30
Interrupt handler
void int_handler(int irq, void *dev_id, struct pt_regs *regs) {
wake_up_interruptible(&queue);
/* Just wake up anything waiting for the device */
}
Arguments to int_handler:
– irq: the number of the interrupt that caused the handler to be run
• One handler could be associated with multiple interrupts
• Somewhat provided for backwards-compatibility (UNIX, etc.)
– dev_id: pointer to device data structure
• Current best way for one interrupt handler to handle multiple devices
– regs: snapshot of the processor’s register state before the processor
jumped to the interrupt handler
• Rarely used, mostly for debugging
Lecture 6
31
Registering an Interrupt Handler
• Once you’ve written your handler, you have to let the
OS know that the handler should be associated with
a specific interrupt
int request_irq(unsigned int irq,
void (*handler)(int, void *, struct pt_regs *),
unsigned long flags,
const char *dev_name,
void *dev_id);
Declared in <linux/sched.h>, see book for details
Lecture 6
32
Inputs to request_irq
• flags: bit vector that gives details about the interrupt
hander’s behavior
– You’ll want to use SA_INTERRUPT, which indicates that the
interrupt handler is “fast,” and can’t be interrupted by another
interrupt
• irq: number of the interrupt that the handler should be
associated with
– Needs to match the interrupt that the device will signal (duh!)
– Bad things happen if two devices/handlers use the same irq
and don’t expect it
• Can share interrupts if the devices and handlers know about it
Lecture 6
33
Security and the Operating System
• Need to control access to hardware devices
• Approach:
– Instructions that directly manipulate hardware resources are
privileged, can only be run by the kernel
– User programs make kernel calls to request that the OS
access hardware, allows OS to set policies
– Note: being logged in as root is not the same thing as
running in kernel mode
• Being root just means that the OS will almost never say “no” to
your request
Lecture 6
34
Next Time
• Hardware/Software Systems on the XUP Board
Lecture 6
35