Computer Science 5352

Advanced Operating Systems

Instructor: Dr. Larry Pyeatt

e-mail: larry.pyeatt@ttu.edu

Course Syllabus and Policy Statement

Computer Science Department Home Page

We will design and develop a complete Operating System Kernel for the ARM processor. The target platform is Balloon 3.0. For development, students will use Virtutech Simics. According to the academic license for Simics, any extensions to Simics that are developed will be made available at least to Virtutech (including device models developed).

Resources

• Virtutech home page
• Balloon Project home page
• Intel XScale Core Developer's Manual
• ARM Instruction Set Information
• PXA270 Developer's Manual
• Cross-compiler information:
  • Source and script for building cross toolchain
  • Newlib
  • Libm
  • crti.asm
  • crtn.asm
  • test.c
  • Building Bare-Metal ARM systems with GNU: Part 1
  • Building Bare-Metal ARM systems with GNU: Part 2
  • Building Bare-Metal ARM systems with GNU: Part 3
  • Building Bare-Metal ARM systems with GNU: Part 4
  • Building Bare-Metal ARM systems with GNU: Part 5
  • Building Bare-Metal ARM systems with GNU: Part 6
  • Building Bare-Metal ARM systems with GNU: Part 7
  • Building Bare-Metal ARM systems with GNU: Part 8
  • Building Bare-Metal ARM systems with GNU: Part 9
  • Building Bare-Metal ARM systems with GNU: Part 10
  • Bran's Kernel Development tutorial
  • Slab memor management
  • Buddy Memory allocation
  • Skeleton for project2
  • Updates of Skeleton for project2
    • vmlarix0802251913.tgz
    • vmlarix0802260226.tgz
    • vmlarix0802261912.tgz
    • vmlarix0802271355.tgz
    • vmlarix0802291353.tgz
    • vmlarix0802291551.tgz
    • vmlarix0803040816.tgz
  • Updates of Skeleton for project3
    • vmlarix0803261130.tgz
    • vmlarix0803281118.tgz
    • STARTING POINT FOR PROJECT 4. Project 3 was too ambitious. We are backing off and taking a smaller piece to work with. The next file is our basic kernel with taska and taskb running in their own virtual memory space, and trying to use a system call. Since ARM_swi has not been implemented, it will stop with a message about software interrupt. Note that the makefiles in usr, usr/programs, and usr/lib may need to be changed to call the correct version of MAKE for your system. For those who want to know, the trick in getting the code to work was moving start_process, save_process, and resume_process from C with embedded assembly to pure assembly. Take home lesson: if you have to do embedded assembly, then you should probably just bite the bullet and write an assembly language subroutine.
  • Updates of Skeleton for project4
    • vmlarix0803281905.tgz
    • vmlarix0804021351.tgz
    • vmlarix0804050951.tgz <== kernel with kmalloc/kfree
  • STARTING POINT FOR PROJECT 5. This version of the kernel has a working (though possibly buggy) filesystem. It also has a kprintf() function, which works like the stdlib printf() function. The kernel expects the RAMdisk to be loaded at address 0xC0700000. You can run this version of the kernel in simics as follows:
    
    dijkstra$ ./simics targets/arm-sa1110/sa1110-linux-common.simics
    simics> load-file vmlarix/ramdisktools/ramdisk1 0xc0700000
    simics> new-symtable
    simics> load-binary "vmlarix/vmlarix"
    simics> st0.load-symbols "vmlarix/vmlarix"
    simics> write-reg pc 0xc0000000
    simics> new-gdb-remote
    simics> continue
    
    
    • vmlarix0804200217.tgz
  • Updates of Skeleton for project4
    • The next file has a working version of the ARM_swi and c_SWI_handler code, plus the open(), read(), and write() system calls are working. User programs can open("/",O_RDONLY,0) and read the entries of the root directory on the ramdisk. The close() system call appears to still have some bugs.
      There are some utility functions for the user programs, included in the user library. There are now several standard string functions and a minimalist version of printf(). printf() uses the write() system call, and writes to file descriptor 0 (just like the real thing!). I still have not found a working fork(), though a couple of students came close.
      There are a couple of good implementations of the process queue, and I will have an update with one of those included as soon as I can.
    • vmlarix0804210031.tgz
    • The next file contains a few more improvements:
      • The read() system call actually works.
      • the ramdisktools subdirectory has two additional programs: copy_to_rd and copy_from_rd. Their function should be self explainatory. Run them without any parameters to get a very terse help. If you type "copy_to_rd thisfile thatramdisk" then it will look in the current directory for thisfile, and copy it into the root directory of the ramdisk in the file thatramdisk (you have to use createramdisk and mkfs_lfs to create the ramdisk). If you type "copy_from_rd thisfile thatramdisk" it will look in the root directory of the ramdisk for a file named thisfile, and copy it to the current directory on the host system.
      • I used the ramdisktools co copy a C file onto the ramdisk. When taska starts, it reads that file and prints it to the screen, then creates a file on the ramdisk. After that, it prints Task A: repeatedly, where is an increasing integer. taskb waits for taska to create the file, then starts printing its own messages.
      • The kernel and filesystem are now complete enough for you to finish the final project. Have fun!
    • vmlarix0804222109.tgz
    • vmlarix0804250852.tgz
    • vmlarix0804250856.tgz
    • vmlarix0804251037.tgz
    • vmlarix0804251121.tgz
  
  
• The ELF Format

Projects

• Project 1
• Project 2
• Project 3 Due March 14.
• Project 4
• Project 5