Porting RtKer to Leon

1
Porting RtKer to Leon

• By
• Ashish Jain Vidyesh Kr. Jha

2
Brief overview of Rtker

• What is Rtker ?
• RTKer stands for Real Time Kernel
• Has some distinguishing features like
• Modularity
• Portability
• Real-time Interrupt Handling
• A Flexible Scheduler
• Has support for architectures like arm, x86,
  Tri-Media and now Sparc V8 as well

3
Main features of Rtker

• Extremely Modular

• Directory based separation of architecture-depende
  nt and architecture- independent code.
• Clear set of functions for thread semaphore
  management, scheduling, context switching.

4
Main features of Rtker

• Easily Portable to different architectures

5
Main features of Rtker

• Pluggable Scheduler
• Flexibility for the application developer to
  specify his own scheduler
• Functions like sched_create_thread() and
  sched_heir_thread() can be defined at the time of
  Rtkers initialization
• Pre-defined schedulers fifo, edf available

6
Main features of Rtker

• Two stage interrupt handling

• Immediate ISR
• Executed as soon as an interrupt is raised.
• Bottom half ISR
• Executed in a thread context typically does
  data transfer to/from the kernel.

7
Sparc Architecture

• 1.General purpose registers are divided into in,
  local, out, global.(32 bits)
• 2.Register Set 8 in , 8 local
• 3.Register Window 8 in, 8 local, 8 out
• 4.Number of Register Windows is implementation
  dependent.
• 5.Tsim-Leon has 8 Register Windows.

8
Windowed Registers

• 1.An instruction can access the 8 global,and
• all 24 Registers in a window.
• 2.NWINDOWS - number of Windows(2 to 32)
• 3.CWP current window pointer.It points to the
  current window
• 4.Instruction can access only registers in the
• Current window.

9
Overlapping of Windows

• 1.Each window shares its ins and outs with the
  two adjacent windows.
• 2.The outs of CWP1 are addressable as ins of CWP
  and outs of CWP are addressable as ins of CWP-1.
• 3.The locals are unique to each window.
• 4.CWP arithmetic is performed modulo NWINDOWS.

10
(No Transcript)
11
Windowed Registers contd.

• 5.CWP incremented by a restore and decremented by
  a save.
• 6.WIM detects whether overflow or underflow has
  occurred.(controlled by supervisor software)

12
(No Transcript)
13
Save

• 1.The Save instruction subtracts one from CWP.
• 2.It then checks new value of CWP against WIM for
  overflow.
• 3.If WIM bit corresponding to current window is
  one then a window overflow trap is generated.
• 4.Else if WIM bit is zero,then no overflow occurs
  and the callers window is saved.

14
Restore

• 1.Restore adds one to CWP and compares this value
  with WIM.
• 2. If corresponding WIM bit is one then window
  underflow trap is generated.
• 3.CWP1 now becomes CWP.
• 4.Callers window is restored.

15
Procedure call conventions

• 1.The caller puts the outgoing parameter in
  register o0-o5 and expects the result in o0.
• 2.Then the caller uses the call instruction to
  transfer control to the called procedure.
• 3.As soon as control is transferred to the callee
  it needs to save the callers register window.
• 4.The callee must also save the address where it
  has to return to.(i7)
• 5.Just before returning back to callers the
  callee does a restore to go back to callers
  window.

16
Procedure call conventions (contd)

• 6.The callee returns to the caller by issuing a
  ret instruction.
• 7.ret nPC i7 8
• 8.Since the callee jumps to return address8 ,the
  caller must write two nops just after call.

17
Our Approach

• 1.We started by getting ourselves acquainted with
  Rtker.
• 2.We stripped oskit-libraries and made RtKer
  oskit independent.
• 3.Booted x86 with Bochs and tested RtKer by
  running the Dining Philosopher application.
• 4.Also tested arm support by running a similar
  application.
• 5.Started studying Sparc V8 architecture
  --Register Windows, Stack Layout, Procedure Call
  conventions,Context Switching.

18
Our Approach (contd)

• 6.Also continued with the study and Inline
  documentation of RtKer
• 7.Wrote the Context Switching code for Sparc in
  RtKer.
• 8.The code simply exited after seeing a trap
  instruction with simulator giving a message of
  program exited normally.
• 9.Eventually after hacking for a couple of weeks
  we found that there was no trap support (Since we
  were writing our OS we had to install trap
  support in it)

19
Our Approach (contd)

• 10.Went through trap handling mechanism of Sparc.
• 11.Got trap handler codes for window-underflow,
  window-overflow,flush-windows from rtems library.
• 12.We tried to set the trap table.
• 13.In the meantime, Anup suggested us to write
  the context switching code without using traps,
  using just saves and restores.

20
Our Approach (contd)

• 14.Basant suggested to look into the setjmp and
  longjmp which are functions to save context and
  load context.
• 15. We wrote a stand-alone code for Context
  Switching between two functions f() and g().
• 17.The code worked well.
• 18.We then transferred the context switch part of
  this code to RtKer and got it working in Rtker
  after a little bit of debugging.

21
Sparc Context Switch

• Algorithm for Context Switch using simple save
  and restore instructions (without using traps) -
• SaveContext
• Disable traps.
• Save pc, sp in the thread context structure
• Store the in and local registers of the current
  register windows on the stack(sp)
• Check condition on wim/CWP. If all windows have
  been saved, then go to step 5, else continue.
• Execute a restore and go back to step 2.
• Save the number of restores executed (say N) in
  the thread context structure.
• Branch to LoadContext.

22
Sparc Context Switch (contd.)

• LoadContext
• Pick up the value of N from the thread context
  structure and execute N saves .
• Pick up the stack pointer(sp) from the thread
  context structure.
• Load the in and local registers with the values
  on the stack.
• Execute a restore.
• Repeat steps 9 and 10 N times.
• Execute N saves to reach the working register
  window.
• Re-enable traps
• Jump to pc 8. (pc is stored in the thread
  context structure

23
Stand alone example code

• toggle 0
• f()
• while(1)
• printf(In f \n)
• toggle 1 toggle
• SaveContext(thread1-toggle, threadtoggle)
• g()
• while(1)
• printf(In g \n)
• toggle 1 toggle
• SaveContext(thread1-toggle, threadtoggle)
• main()

24
Developing Sparc support in Rtker

• Steps followed
• Redefining the thread context structure.
• Change in Context Initialization code.
• Few changes in Rtkers initialization code.
• Finally, porting the Context Switching code from
  stand alone example code to Rtker, with slight
  modifications.

25
CPU_Context_Initialize

• void CPU_Context_Initialize(struct reg_context
  the_context,
• void stack_base,unsigned int stack_size,
• void (entry_point)(void ()(void ),void ),
• void (thread_fun)(void ), void thread_arg)
• unsigned int stack
• stack((unsigned int)stack_base)stack_size-96
  the_context-gtr0 stack / stack pointer
  / the_context-gtr1 (unsigned
  int)entry_point-8
• / helper function /
• the_context-gtr3 0 / No. of
  register windows in use
  / the_context-gtr4 (unsigned int)thread_fun
• / First Argument / the_context-gtr5
  (unsigned int)thread_arg
• / Second Argument /

26
General structure of Applications

• define scheduler functions like heir_thread(),
  reset_thread() etc.
• define thread tcbs
• initialize the scheduler with main_tcb as
  THREAD_ON_CPU
• main()
• initialize Rtker with the scheduler and
  initialize the interrupt timer
• create a thread
• create another thread
• suspend the main thread

27
Next step

• Port Rtker to Leon
• Extension to multiprocessor Leon

28
Thank You
29
(No Transcript)
30
(No Transcript)
31
Main features of Rtker

• Device Driver Framework
• Motivation To keep Rtkers Device Driver
  Framework compatible with that of a standard OS
  like Linux.
• The notion of glue code in Oskits framework
• Rtkers implementation of functions of Oskits
  device driver framework