About Publications Downloads Related Projects Team L4hq.org  
 
Projects
Pistachio
Kickstart
Download
Virtualization
Pre-virtualization
Device Drivers
Multiprocessor
Marzipan
BurnNT
IDL4
Release Notes
Documentation
Persistence
Hazelnut
Download
Getting started
 
Miscellaneous
Mailing lists
Tools
VMwareGateway
Workshops
Google L4Ka.org:
 
 

L4Ka::Pistachio/mips64

page maintained by Carl van Schaik (cvansch@cse.unsw.edu.au)

Welcome to the home of the L4Ka::Pistachio kernel for the Mips64.

Supported Hardware

The kernel has been extensively tested on the UNSW in house R4k (u4600) system. Systems utilizing the R5000 and Sibiyte are also supported, however these platforms have not been extensively tested. Experimental work has shown that the port runs on the Sulima MIPS simulator.

Tested Hardware

We have limited access to Mips64 hardware. The following systems have been tested:

UNSW U4600 - IDT R4400 CPU (Big Endian) Complete support
OpenFuel R5000 - IDT 79RC64574 (Little Endian) The kernel runs, however has been less tested.
Sibyte SB1 The kernel runs, however has only been very lightly tested. At present disabled due to GPL code and lack of testing.
The kernel should be trivially portable to any 64-bit MIPS system.

Performance

We have not subjected the kernel to large scale benchmarks, however we have experimental IPC times using an assembly fastpath of approximately 103 cycles each way (measured on the u4600 and R5000 systems). We have subjected the kernel to high loads using the Mungi Operating System.

Missing Features and Known Bugs

The following are known issues with the Mips65 L4Ka::Pistachio kernel:
  • The following system calls are unimplemented:
    • SystemClock
    • ProcessorControl
    • Lipc Use the Ipc system call instead.
  • SMP is not supported.
  • Exceptions are not delivered to the user. Any exception which cannot be handled by the kernel causes the debugger to be invoked.
  • Floating point virtualization is not implemented; as a consequence, user code may not use floating point instructions.
  • Some code cleaning is necessary; sections of the implementation are still first generation.
   
 
 
 
  Mail to webmaster   © 2000-2008 University of Karlsruhe