CS452 - Real-Time Programming - Spring 2013

Lecture 10 - Name Server

Pubilc Service Annoucements

1. Due date for kernel 2: 3 June.
2. I kept a list of submitters whose issues were serious enough to note for

   future reference:

   * s23liang: Scheduler bug (minor, reversing some orders), no kernel stack

   or context.

   * bliu: Scheduler needs more priorities (currently has four). User stacks

   live in the kernel stack.

   * chfoo: Saving registers before and after SWI. No true kernel stack

   (uses brittle bad method). Too few priorities, linear search as well.

   * f2fun: Provided little to no documentation at all. There was a single

   page. No program output.

   * j3you: Saving registers in the wrong place as well (before / after

   SWI).

   * x4xi: Uses a very brittle kernel data structure methodology. Not

   terrible, but not good either.

   * aitskovich: Only supports 5 tasks. Task memory inside task descriptors

   in the kernel.

   * ck2hung: No working context switch.

   * J346zhang: Not saving temporary registers etc. Could run out of TIDs.

   Linear scheduling (4 priorities).

   The most serious issue was with ck2hungâs group, which had no working

   context switch. There was a bit of ignoring my post / not reading

   documentation (one group is losing unnecessary marks because they simply

   didnât include the user program output or explain anything). Another group,

   chfooâs, was dumping and loading all registers to the stack in user space,

   before and after the SWI call, for seemingly no reason at all.

   There were also some unusual bad choices this term (they seem to spread

   organically), in addition to the usual types. In particular:

   * Linear search scheduling, or having only 3-4 priorities available to

   the kernel.

   * User stacks that live on the kernel stack.

   * Not giving the kernel its own context. Several groups seemed to eschew

   memory division entirely and just say âthere is a struct that lives at

   a static place, we will always pull items from here and never restore

   the kernel stack pointer properlyâ. These same groups also decided that

   restoring the kernelâs link register would be onerous and decided to

   simply branch to a handler function on kerenter.

   * Saving registers in the wrong locations, or not saving registers at all

   (r0-r9ish were completely ignored by one particular group).

   .

Hardware Interrupts

What is a Hardware Interrupt?

In the CPU

1. Test interrupt signal before fetching the next instruction
   • actually AND of INT and the IRQ bit in the CPSR
2. If asserted, change mode to IRQ
3. Disable interrupt in CPSR
4. Put CPSR into SPSR_irq
5. Execute instruction at 0x18

In the Interrupt Control Unit (ICU)

• Several interrupts may be present
  • There are two options for deciding which one to service
    1. Software
       • Check ICU status registers to discover which interrupt(s) are present
       • Run an algorithm that decides which one to take
       • This permits context-dependent priorities
    2. Hardware
       • Program the ICU to a set of fixed priorities
       • Entry point of highest priority interrupt appears in ICU
       • Jump to it without requiring software priority resolution.
• Handling one interrupt sometimes exposes another one

In the Peripheral Hardware

• Several interrupt conditions may be present at one time
  • ORed in peripheral hardware
  • ORed in glue hardware
  • Rare that there is a priority mechanism
• Handling one interrupt sometimes exposes another one

When two interrupts are present

What should happen?

1. Kernel executes with interrupts disabled.
2. Context switch into user task turns on interrupts.
3. Before fetching the first user task instruction test IRQ input.
4. If asserted, re-initiate interrupt processing.

Context Switches for Interrupts

Difference from Software Interrupts

It is impossible to predict when hardware interrupts occur ( = where the PC is)

• Software intterrupts occur at only a few places in the code.
• You may have a kernel that takes this predictability for granted.

Assymmetry between User Task and Kernel

For the interrupted task,

1. scratch registers must be saved and restored, including IP
2. stack pointer must be stored
3. two link registers must be kept separate

For the kernel,

1. no need to save scratch registers
2. stack pointer preserved in S13_svc
3. link register preserved in R14_svc

Two Link Registers

1. One to return from interrupt
   • In the registers of the interrupt handling code
   • To return to the interrupted task in the right place
2. One to move to the caller's stack frame
   • In the registers of the interrupted task
   • To return to whatever started in interrupted task

Helpful Features of the ICU

1. Several places where you can read state
2. Several places where you can block interrupt flow
3. Trigger hardware interrupt from software
   • What makes interrupts hard is that you are doing two semi-hard things at once
     1. Making the hardware produce the interrupt
     2. Responding to the interrupt
   • This allows you to separate them in developing/debugging

The Hardware in the Trains Lab

32-bit Timer

Base address: 0x80810080

Three registers:

Interrupt Control Unit (ICU)

The actual device is the ARM PL190

The logic in this design is completely asynchronous, so it functions when the CPU clock is turned off.

• Important (= essential) for low power operation.

All input signals are

• active high
• level sensitive

Base addresses

• VIC1: 0x800B0000
• VIC2: 0x800C0000

Basic Operation

VIC powers up with

• all vectored interrupts disabled.
• all interrupts masked
• all interrupts giving IRQ

Procedure

Initialization

1. leave protection off
2. enable in VICxIntEnable when you are ready to handle the interrupt

On an interrupt

1. Read VICxIRQStatus
2. Choose which interrupt you wish to handle
3. Clear the interrupt source in the device

For debugging

1. Use VICxSoftInt and VICxSoftIntClear to turn interrupt sources off and on in software

Hardware Definitions

Helpful Features of the ICU

1. Several places where you can read state
2. Several places where you can block interrupt flow
3. Trigger hardware interrupt from softwareonce
   1. What makes interrupts hard is that you are doing two semi-hard things at once
      • Making the hardware produce the interrupt
      • Responding to the interrupt
   2. Software interrupt generation allows you to separate them in developing/debugging

Non-vectored Operation

Initialization

1. Enable interrupts in device
2. Enable interrupts in ICU
3. Enable interrupts in CPU, usually by MOVS

Interrupt occurs

1. AND of IRQ and NOT( IRQ disabled bit in CPSR ) is checked before each instruction fetch.
2. If set IRQ exception is taken in place of next instruction fetch.
   • Possibly zero instructions of active task are executed.
   • Make sure that this case works
3. Context switch into kernel

   ---

   Context switch novelties

   Difference from Software Interrupts

   • It is impossible to predict where they occur
   • You may inadvertently have made some assumptions about when they occur
   • Scratch Registers must be saved
     • r0-3
     • IP -- used only very occasionally by gcc
   • Two Link Registers
     • One to return from interrupt
     • One to return from the interrupted task to whatever called it

   ---

4. Turn off interrupt in device
   • Should turn off interrupt in ICU
   • What about IRQ?

You are now ready to process the interrupt in the kernel

Return to:

• Bill Cowan's lecture notes for CS452 in s13
• Bill Cowan's Spring 2013 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page