| layout | title | group |
|---|---|---|
page |
Wishlist |
{% include JB/setup %}
We have a list of projects, some of which are currently in progress, and some of which we want others to start work on.
OpenRISC is a very broad project and there is likely something to do for any discipline. That said, below are some projects we have identified and would like help solving.
Taking responsibility for maintaining a package is a great way to gain experience of practical program management. If you are a student, or early in your career, it adds important credibility to your resume. And since it is all open source, your expertise can be publicly verified by any potential employer.
To take part, post a message on the mailing lists, or email the Release Manager, Julius Baxter or come and talk to us on IRC.
Brief explanation: OpenRISC project main problem is difficulty in creating a full system design (CPU, switch, peripherals) and visualizing them.
Task is to create a tool to solve this problem.
Several approaches are possible:
- You'll design Mercurial/Git/Npm like tool for OpenRISC system design. By executing 'openrisc init' empty system will get created, by doing 'openrisc create switch' switch will be placed in the system etc.. Example:
openrisc init
openrisc create switch sw0
openrisc create cpu -t or64k cpu0
openrisc connect sw0.m0 cpu0.s_inst0
openrisc connect sw0.m1 cpu0.s_data0
etc
-
you'll pick and define DSL (Domain Specific Language) for system description
-
you'll use YAML/JSON as system description.
Expected results: Make it easier to create OpenRISC systems.
Knowledge Prerequisite: Any scripting language. System design and computer architecture knowledge
Mentor: Wojciech Koszek wkoszek@freebsd.czest.pl
Brief explanation: OpenRISC needs easy-to-use system for showing how system looks like in a graphical way. Think of connecting boxes together with each other on the schematics. There's no way to do this now in OpenRISC, since there's no software.
Expected results: Goal is to:
-
understand HW/SW elements in modern embedded systems.
-
figure out in JQuery/Javascript/HTML5 how to write an application with drag&drop capabilities to place CPU (1 box), Switch (1 box) and some other blocks, and wire them all together. Then store this config in memory somehow (JSON) and preserve it on the client side (LocalStorage on HTML5) and submit it to the server.
-
server should at least receive it
Knowledge Prerequisite: HTML5, Jquery, Graph/chart javascript library (d3?)
Mentor: Wojciech Koszek wkoszek@freebsd.czest.pl
Brief explanation:
If you look how most software people install packages, you'll see how easy it is.
Hardware people don't have this notion of installation. Installing Wishbone/OpenRISC modules is a whole bunch of pain and nostalgia.
The idea is to solve the problem with packages, so that constructing a system would be easily possible by just typing couple of commands, which would fetch RTL sources and prepare the blocks together for you, so you can easily simulate them. RTL poses new challenges:
-
upon fetching, stuff should be simulated and verified to meet the specs
-
it should be matched like shared libraries, since some versions of a switch may not work with the CPU
-
should be tagged: WishBone stuff can't work with AXI interconnect stuff. It'd be nice to do:
openriscpkg install openrisc
openriscpkg install wb_mux
openriscpkg install wb_uart
openriscpkg sim wb_mux
openriscpkg package wb_mux
Knowledge Prerequisite:
Any scripting language.
System design and computer architecture knowledge
Understanding of Verilog
Willingness to learn of Wishbone architecture
Brief explanation:
Linux is the only operating system running on OpenRISC. Proposal is to offer alternative software stack for OpenRISC users by porting FreeBSD OS to OpenRISC.
Task would involve:
- running or1ksim and getting basic Hello world running
- installing FreeBSD in VM
- porting FreeBSD to 'accept' new OpenRISC toolchain on FreeBSD
- making OpenRISC toolchain work
- porting FreeBSD kernel to OpenRISC
MVP for this product would be minimal kernel that can boot inside of OR1KSIM and print something on UART. We'd expect kernel should reach driver execution stage.
Knowledge Prerequisite:
Advanced ANSI C knowledge
OS design and architecture.
Computer architecture
Compiler understanding
Brief explanation: Syscalls are expensive. VDSO helps speeding this up.
This is probably a small project. For GSoC it might be suitable to combine with other projects.
Since or1k does not contain any atomic operations these are implemented as syscalls. With VDSO these should perform much faster.
Expected results: Faster syscalls, better multi-threaded performance.
Knowledge Prerequisite: C, How to build a Linux kernel
Mentor: Christian 'bluecmd' Svensson
Brief explanation: OpenRISCs GCC disables languages such as Go, Java, D etc. This project would be to:
- Find out what kind of work is needed to make these languages available (libffi for one).
- Prioritize with the community.
- Start implementation of dependencies and the language support.
- Set up regression testing.
- Document usage and caveats.
Expected results: Increase programming languages available on OpenRISC.
Knowledge Prerequisite: C, Linux internals
Mentor: Christian “bluecmd” Svensson
Brief explanation: GDB running in userspace for Linux is in a weird state.
As far as bluecmd knows GDB should work on bare metal, but not for userspace Linux. It would be good to clean this up, make it work and upstream it.
The project would be something like this:
- Find out what works and does not work with the GDB as it is today
- Fix GDB
- Set up automatable regression testing
- Document how to use
- Upstream the patches
Expected results: GDB running on OpenRISC under Linux
Knowledge Prerequisite: C, Linux internals
Mentor: ? (maybe bluecmd)
Brief explanation: This project would be to take a look on how to port libraries that needs to know stuff about the machine it's running under. Libffi and gobject-introspections are two examples of this.
libffi provides interfaces to C functions for programs like Python. Not having it is a bit of a pain.
GObject-introspection is a C wrapper for GNOME objects. It is rumored that this is a bit tricky to port, but that is only rumor.
This is a smaller project, possibly part of the Extend language support project. Some work has been started by Sebastian Macke: https://github.com/s-macke/libffi
Expected results: Wider support and more software available
Knowledge Prerequisite: C
Mentor: Christian “bluecmd” Svensson
Brief explanation: The various implementations (mainly OR1200, or1ksim) need to be updated to support the versioning system which is new to OR1K version 1.0.
Specifically, VR2 and ISRs should be implemented and containing meaningful values.
Any software bundled with these implementations, and the libraries such as newlib, should be updated, too (at the very least the spr-defs.h files should be updated - patches for this do exist but need to be committed.)
Once models look to be working OK with the new versioning scheme, things like the Linux kernel port should be updated to support the new system.
Expected results: ?
Knowledge Prerequisite: ?
Mentor: ?
Brief explanation: Our toolchains are looking better and better. A bigger and bigger issue is having to merge with upstream. It would be very nice if we could come up with a plan and begin merging the work with upstream.
A big part of this is to figure out what code is used and written by whom. We have revision histories spanning back to when CVS was used, over to SVN and finally Git.
Expected results:
- Easy usage for people, no need to pull patches from our repositories.
- Less administrative burden for OpenRISC.
- Needed for stuff like Debian.
Knowledge Prerequisite: Revision Control Systems
Mentor: ?
TODO: FORMAT TO TEMPLATE
The objective is to bring OR1200 specification document into line with what is actually in the RTL. A few sections still need going over (debug interface, for one.)
This task is being handled by Yann Vernier [mailto:yann@orsoc.se yann@orsoc.se].
TODO: FORMAT TO TEMPLATE
This is being led by Michael Unneback (michael@orsoc.se).