CS452 - Real-Time Programming - Spring 2012

Lecture 31

- Power On

Public Service Annoucements

1. Final exam date: 9.00 August 7 to 11.30 August 9

Power On

Initial state

ARM

Cirrus

Technologic

The following things, which are described in the Technologic documentation, manual & circuit diagram, are properties of the TS7200

1. Boot control bits, set to normal boot, 32-bit bus width, sychronous boot device, internal, watchdog timer disabled.
2. Physical memory map
   • 0x80000000 to 0x800fffff, used by Cirrus for on-chip components
   • SDRAM chips break memory into 4M blocks. Addresses of 4M blocks are
     • 0x00000000 to 0x003fffff
     • 0x00400000 to 0x007fffff
     • 0x00800000 to 0x00bfffff
     • 0x00c00000 to 0x00ffffff
     • 0x01000000 to 0x013fffff
     • ...
   • TS7200 uses 4-bit chip select to divide the memoery into 256 Mbyte blocks
     • 0x00000000 to 0x0fffffff (first 256M) SDRAM, CS0, 32 bus cycles
     • 0x10000000 to 0x1fffffff: CS1, 8 bit bus cycles
     • 0x20000000 to 0x2fffffff: CS2, 16 bit bus cycles.
     • 0x60000000 to 0x7fffffff: CS6/7, Flash
     • 0x80000000 to 0x8fffffff: I/O registers including
       • 0x80000000 to 0x807fffff: AHB mapped registers, including
         • DMA
         • Ethernet
         • USB
         • Memory controllers
         • Pre-pre-boot ROM
         • ICU registers
       • 0x80800000 to 0x8fffffff: I/O registers

     SDRAM chips break memory into 4M blocks. Addresses of 4M blocks are

   • 0x00000000 to 0x003fffff
   • 0x00400000 to 0x007fffff
   • 0x00800000 to 0x00bfffff
   • 0x00c00000 to 0x00ffffff
   • 0x01000000 to 0x013fffff
   • ...
3. In the AHB registers is a 16K block of ROM from 0x80090000 to 0x80093fff
   • Initially, it is mapped to the entire memory space at 16K intervals.
   • Chip select, and how addressing occurs.
     • Chip select of this block is 0x8009[00XXb]XXX
     • Chip select has two parts
       • I/O chip select: 0x8XXXXXXX
       • AHB chip select: 0xY00XXXXX
       • ROM chip select: 0xYYY9[00XXb]XXX
   • The first instruction executed is the one that you find at 0x80090000

Pre-pre-boot Sequence

1. Jump to 0x80090018.
2. Turn on LEDs
3. Make the CPU completely vanilla. E.g.,
   • no caches, physical memory map,
4. Turn off watchdog timer
5. Configure external clocks (needed for serial boot)
6. Acquire boot state configuration inputs
   • These are input pins on the EP9302, the state of which is determined by the TS7200.
   • A couple are user-controllable via jumpers
   • They are the only thing the EP9302 knows about the outside world
7. Using boot state configure
   • flash memory controller
   • SDRAM memory controller

   These are configured with very conservative parameters

8. Clear boot mode `memory map'
9. Toggle LEDs
10. Switch
    • Serial boot on UART1
      1. Output ">"
      2. Read 2048 bytes starting with CRUS or SURC to the Mac FIFO
      3. Jump to the start of the Mac FIFO
    • Boot from ROM outside SoC
      1. Assert ROM chip selects looking for CRUS
      2. When found read 2048 bytes from the ROM to Mac FIFO
      3. Jump to the start of the Mac FIFO
    • Boot from flash
      1. Look for CRUS at possible flash start locations
      2. When found jump to start location plus 0x4 (account for CRUS)
    • If not found
      • if 0x0 writable destination is SDRAM else destination is Mac FIFO
      • load 20 words into destination
      • flash LEDs forever
11. In the first two cases the 2048 bytes contains a memory test followed by a loader.
12. The Mac FIFO code is used for premature death in the pre-boot also.

Pre-boot Sequence

This code knows all about the EP9302, and all about the TS7200.

1. Sets up a stack in the ethernet buffer
2. Sets the CPSR to a vanilla state: no interrupts, svc mode
3. Copies 80 words of code from flash to the ethernet buffer
4. Initializes memory controllers for the memory it has
5. Configures GPIO.
6. Turns off the watchdog timer
7. Sets up the appropriate serial port for a monitor
8. loads RedBoot

Can Message Passing be Made Type Safe?

Dynamically

Yes, even including type extension and polymorphism, but

• What does the program do when it detects a type mismatch?
• Well, it could send a more informative error message before it dies.

Statically

No,

• Structured programming depends critically on well-defined scope.
• While tasks are scoped internally, there is no inter-task scoping.
• In fact, we are happy to be free of scoping, because it allows us to try out a wider variety of program structures.

CSP

To formal methods people CSP is a calculus for reasoning about the correctness of multi-process/threaded/tasking (MPTT) systems. Active research has been ongoing for forty years with several goals

• translating other synchronization/communication semantics to and from CSP
• finding new methods for reasoning about CSP
• scaling everything to make CSP useful for production sized programs
• During that time many a chicken has left its tracks on the pages of formal methods journals and conference proceedings!

For programmers the claim has been and is made that CSP provides a superior method for structuring MPTT systems. (`Superior' in the sense of `easier to design, implement and understand'.)

• The claim was first made in the late 1970s/early 1980s.
• It was made again in the early 1990s, this time with the weight of Bell Labs behind it.
• And has been made yet again in the last few years, this time with the weight of Goggle behind it.

Primitives

In CSP there are two communication primitives. In the notation of occam 2/Go, they are

1. read

   keyboard ? ch
   ch = <- keyboard

   • reads from an input channel called keyboard and assigns what it reads to the variable ch
   • the channel must have an associated type, and the type must match the type of the variable.
   • That is, the channel and the variable must be in the same scope.
   • read blocks until input is available on the channel
2. write

   keyboard ! duh
   keyboard <- duh

   • writes the value of the variable duh into the channel keyboard
   • write does not block
   • Thus, a read/write pair guarantess that read in the reading process occurs simultaneously with or after the corresponding write in the writing process.

The communication primitives require something new, called a channel.

CHAN OF CHAR keyboard
keyboard chan char

• A channel is a first in/first out silo.
• Each channel has a protocol that states the type that messages it handles must have.
• Knowing the name of a channel is essential for using it.
  • Applications control who can be on the other end of a channel, which is essential for security, by controlling who knows the name of the channel.

The Transputer

Use many co-operating, medium capability microCPUs to do a big job.

• An idea whose time has now come.
• Google

Problem is communication

• Big granularity (thick client: MS, Google)
  • minimizes communication
  • maximizes replicated data
  • The Google approach:
    • an opportunity nobody thought about
    • a problem nobody thought about.
• Small granularity
  • minimizes replicated data
  • maximizes communication
  • Your system, like threading solutions, relies on shared memory for communication
    • The return of the FORTRAN common block
    • How would you handle caching?

Communication requires either

• a common bus, star topology
  • system bus (= shared memory)
  • LAN
• a common channel, over which users pass messages in real-time
  • wasteful of bandwidth
  • analogue telephony
• passing messages along
  • emphasizes the switches (bridges) that connect common buses
  • really more like a hybrid, which is classified differently based on the level of abstraction.

What about real-time?

• lots of timer (countup) hardware
  • interaction of countdown and countup to make your clock server
• Instances of timers are not guaranteed to be synchronized
  • How could two timers be synchronized?

The transputer was an early, now vanished, example of a real-time system based on plentiful small granularity communication. Your kernel is another example.

• Your kernel: communication based on shared memory, which is easy to program, hard to make secure.
• The transputer: communication based on switch mediated packets, which is hard to program, easy to make secure.

Transputer hardware

• CPU, memory, switch on one chip
• chips connected in an array
• presumably a run-time system decides where tasks will go in order to
  • maximize CPU throughput
  • minimize communication overhead

Occam 2

Basic idea

1. processes (tasks)
   • may be named, take arguments and return values
   • may be combined
2. CSP channels
3. time

Combining processes

1. sequential
2. conditional
   • if/then
   • selection by case
3. looping
   • without test/break
   • with test/break
4. parallel
   • initiated when the keyword PAR occurs.
5. alternation
   • guarded alternatives
   • if more than one guard is true then select at random
     • can be prioritized

Time

• timer returns time as channel input

  clock ? now

• AFTER can be used to combine times, because there is a total order based on time

  IF now AFTER yesterday THEN

• AFTER can make timer input blocking

  clock ? AFTER tomorrow

Can you Build a Server with Type-Checking?

Outer
Scope
|
| CHAN OF REQUEST request
|
| Server 
| Scope
| |
| | REQUEST sreq
| | CHAN OF REPLY srep
| |
| | request ? sreq
| | srep := sreq.reply
| |
| | srep ! sresult
| |
| |
| |
| Client
| Scope
| |
| | REQUEST creq
| | CHAN OF REPLY crep
| |
| | creq.reply := crep
| | request ! creq
| |
| | crep ? cresult
| |
 

The Result

You can write a type-safe server, BUT

• all possible clients must be in the same scope in order to get static type checking
• with dynamic, structural type checking you only need to have the tasks written in languages having the same type system

BUT

with this structure excessive code in the client weakens synchronization, which might not be what you want.

Return to:

• Bill Cowan's lecture notes for CS452 in s12
• Bill Cowan's Spring 2012 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page