SX support added

July 03, 2013 posted by Michael Lorenz

Support for Sun's SX rendering engine ( found in the SparcStation 20 and 10SX's memory controllers ) has been added, both for the console and X. Both drivers support basic acceleration ( block copy, rectangle fill, character drawing in the kernel ), the Xorg driver also supports Xrender acceleration. This probably makes SX the oldest supported hardware which can do that.

[Read More] [0 comments]


Google Code-In 2012/2013 (from jdf)

July 02, 2013 posted by Matthew Sporleder

Google Code-In (GCi) is a project like Google Summer Of Code (GSoC), but for younger students. While GSoC is aimed at university students, i.e. for people usually of age 19 or older, GCi wants to recruit pupils for Open Source projects.

When applying for participation, every project had to create a large number of potentially small tasks for students. A task was meant to be two hours of work of an experienced developer, and feasible to be done by a person 13 to 18 years old. Google selected ten participating organisations (this time, NetBSD was the only BSD participating) to insert their tasks into Google Melange (the platform which is used for managing GCi and GSoC).

Then, the students registered at Google Melange, chose a project they wanted to work on, and claimed tasks to do. There were many chats in the NetBSD code channel for students coming in and asking questions about their tasks.

After GCi was over, every organisation had to choose their two favourite students who did the best work. For NetBSD, the choice was difficult, as there were more than two students doing great work, but in the end we chose Mingzhe Wang and Matthew Bauer. These two "grand price winners" were given a trip to Mountain View to visit the Google headquarters and meet with other GCi price winners.

You can see the results on the corresponding wiki page

There were 89 finished tasks, ranging from research tasks (document how other projects manage their documentation), creating howtos, trying out software on NetBSD, writing code (ATF tests and Markdown converters and more), writing manpages and documentation, fixing bugs and converting documentation from the website to the wiki.

Overall, it was a nice experience for NetBSD. On the one hand, some real work was done (for many of them, integration is still pending). On the other hand, it was a stressful time for the NetBSD mentors supervising the students and helping them on their tasks. Especially, we had to learn many lessons (you will find them on the wiki page for GCi 2012), but next time, we will do much better. We will try to apply again next year, but we will need a large bunch of new possible tasks to be chosen again.

So if you think you have a task which doesn't require great prior knowledge, and is solvable within two hours by an experienced developer, but also by a 13-18 year old within finite time, feel free to contact us with an outline, or write it directly to the wiki page for Code-In in the NetBSD wiki.

[1 comment]


jdf's Summer of Code project

June 27, 2013 posted by Matthew Sporleder

Julian Djamil Fagir wrote a blog post about his GSoC project

As one of five, I've been chosen for participating in Google Summer Of Code (GSoC) this year for NetBSD. My project is to write a binary upgrade tool for NetBSD, optionally with a “live update” functionality.

Why an upgrade tool? – Yes, updating currently is easy. You download the set tarballs from a mirror, unpack the kernel, reboot, unpack the rest, reboot, and done. But this is an exhausting procedure, and you have to know that there are actually updates, and what they affect.

read more


Support for Marvell Armada XP

May 30, 2013 posted by Radoslaw Kujawa

NetBSD now includes support for Marvell Armada XP SoCs. The port was done by Semihalf and sponsored by Marvell, who have generously agreed to release the source code.

This work was integrated into the NetBSD/evbarm port. The kernel for Armada XP is built from the "ARMADAXP" configuration.

Currently supported hardware include Marvell DB-MV784MP-GP development boards. Adding support for more Armada XP-based boards should be relatively easy.

The port includes support for the PJ4B CPU core and most of the SoC's peripherals:

  • UART
  • SATA
  • PCI Express
  • I2C
  • SPI
  • USB

SMP and on-chip Ethernet are not supported yet (however it is possible to use a PCI Express based Ethernet card). [1 comment]


NetBSD's Google Summer of Code™ Projects 2013

May 28, 2013 posted by S.P.Zeidler

The following projects have been chosen for Google Summer of Code™ this year (sorted by student's last name):
  • Port Linux's drm/kms/gem/i915
  • Student: Myron Aub
  • System upgrade
  • Student: gnrp
  • Implement file system flags to scrub data blocks before deletion
  • Student: Przemyslaw Sierocinski
  • Make NetBSD a supported guest OS under VirtualBox
  • Student: Haomai Wang
  • Defragmentation for FFS in NetBSD
  • Student: Manuel Wiesinger

We hope these students will have an interesting, successful, and also fun summer working with us, heap glory upon their names and do their mentors proud. :)

We thank all students who discussed and submitted proposals; as in every year, slots are limited and we have to let go worthy proposals. [2 comments]


Firefox on sparc64

May 26, 2013 posted by Martin Husemann

New firefox will be available for NetBSD/sparc64 again starting with the import of the official version 22 release into pkgsrc.[Read More] [4 comments]


beaglebone docs pointer -- needs improvement

May 25, 2013 posted by Matthew Sporleder

NetBSD works on the BeagleBone and improvements continue to happen, but we could use some help updating the docs.

If you are using the port (or want to) make sure you email www with some improvements to the BeagleBone wiki page. [0 comments]


NetBSD 6.1 (and 6.0.2!) Released

May 18, 2013 posted by Jeff Rizzo

The NetBSD Project is pleased to announce NetBSD 6.1, the first feature update of the NetBSD 6 release branch. It represents a selected subset of fixes deemed important for security or stability reasons, as well as new features and enhancements.

Simultaneously, the NetBSD Project is pleased to announce NetBSD 6.0.2, the second security/bugfix update of the NetBSD 6.0 release branch. It represents a selected subset of fixes deemed important for security or stability reasons, without new features.

For more details, please see the 6.1 release notes and the 6.0.2 release notes

Complete source and binaries for NetBSD 6.1 and 6.0.2 are available for download at many sites around the world. A list of download sites providing FTP, AnonCVS, SUP, and other services may be found at [3 comments]


NetBSD 6.1 Release Candidate 4

May 02, 2013 posted by Jeff Rizzo

The fourth release candidate of NetBSD 6.1 is now available for download at: It is expected that this will be the final release candidate, with the official release following very soon.

(Please note that while the third release candidate (RC3) was tagged and built, it was never officially released)

NetBSD 6.1 will be the first feature update for the NetBSD 6 branch. There are many new drivers, some new features, and many bug fixes! Fixes since RC2 include:

  • Updated the fix for SA-2013-003 (RNG bug may result in weak cryptographic keys)
  • Fixes to npfctl(8) parsing and error handling
  • Fix sendto(2) issue with IPv6 UDP datagrams. PR#47408.
  • Raspberry Pi: fix handling of large packets in USB host controller
  • Fixed an RPC memory corruption issue. PR#13082
  • Fixed ACPI issues affecting some AMD systems. PR#47016, PR#47648.
  • Change vax MAXPARTITION from 16 to 12, addressing boot issues on some systems
  • Bump libpthread minor version to for the addition of pthread_cond_setclock() earlier in the 6.1 release cycle; note that this is *NOT* the same as in NetBSD-current. ( in NetBSD-current is already at version 1.2)
  • Provide libc stubs to libpthread, allowing libpthread to be dlopen()ed.
  • Fix a userland-triggered panic on x68k systems.

A complete list of changes can be found at:

Please help us test this and any upcoming release candidates as much as possible. Remember, any feedback is good feedback. We'd love to hear from you, whether you've got a complaint or a compliment.

[1 comment]


Thylacine USB driver

April 28, 2013 posted by Blog Import

Zorro attachment code for slhci(4) driver was added. Thylacine USB card is now supported. However, so far only keyboards and mice work reliably. To use them instead of standard Amiga keyboard and mouse wscons kernel is required. [0 comments]


XM6i ver 0.41

April 25, 2013 posted by Blog Import

XM6i version 0.41 has been released. Now XM6i supports MC68881 FPU emulation and the performance of NetBSD/x68k on XM6i is notably improved. XM6i's FPU emulation code was based on NetBSD/m68k FPE sources, and then the XM6i developments also improve NetBSD/m68k FPE implementation. [0 comments]


A Rump Kernel Hypervisor for the Linux Kernel

April 23, 2013 posted by Antti Kantee

Ever since I realized that the anykernel was the best way to construct a modern general purpose operating system kernel, I have been performing experiments by running unmodified NetBSD kernel drivers in rump kernels in various environments (nb. here driver does not mean a hardware device driver, but any driver like a file system driver or TCP driver). These experiments have included userspaces of various platforms, binary kernel modules on Linux and others, and compiling kernel drivers to javascript and running them natively in a web browser. I have also claimed that the anykernel allows harnessing drivers from a general purpose OS onto more specialized embedded computing devices which are becoming the new norm. This is an attractive possibility because while writing drivers is easy, making them handle all the abnormal conditions of the real world is a time-consuming process. Since the above-mentioned experiments were done on POSIX platforms (yes, even the javascript one), the experiments did not fully support the claim. The most interesting, decidedly non-POSIX platform I could think of for experimentation was the Linux kernel. Even though it had been several years since I last worked in the Linux kernel, my hypothesis was that it would be easy and fast to get unmodified NetBSD kernel drivers running in the Linux kernel as rump kernels.

A rump kernel runs on top of the rump kernel hypervisor. The hypervisor provides high level interfaces to host features, such as memory allocation and thread creation. In this case, the Linux kernel is the host. In principle, there are three steps in getting a rump kernel to run in a given environment. In reality, I prefer a more iterative approach, but the development can be divided into three steps all the same.

  1. implement generic rump kernel hypercalls, such as memory allocation, thread creation and synchronization
  2. figure out how to compile and run the rump kernel plus hypervisor in the target environment
  3. implement I/O related hypercalls for whatever I/O you plan to do

Getting basic functionality up and running was a relatively straightforward process. The only issue that required some thinking was an application binary interface (ABI) mismatch. I was testing on x86 where Linux kernel ABI uses -mregparm=3, which means that function arguments are passed in registers where possible. NetBSD always passes arguments on the stack. When two ABIs collide, the code may run, but since function arguments passed between the two ABIs result in garbage, eventually an error will be hit perhaps in the form of accessing invalid memory. The C code was easy enough to "fix" by applying the appropriate compiler flags. In addition to C code, a rump kernel uses a handful of assembly routines from NetBSD, mostly pertaining to optimizations (e.g. ffs()), but also to access the atomic memory operations of the platform. After assembly routines had been handled, it was possible to load a Linux kernel module which bootstraps a rump kernel in the Linux kernel and does some file system operations on the fictional kernfs file system. A screenshot of the resulting dmesg output is shown below.

fs demo screenshot

It is one thing to execute a computation and an entirely different thing to perform I/O. To test I/O capabilities, I ran a rump kernel providing a TCP/IP driver inside the Linux kernel. For a networking stack to be able to do anything sensible, the interface layer needs to be able to shuffle packets. The quickest way to implement the hypercalls for packet shuffling was to use the same method as a userspace virtual TCP/IP stack might use: read/write packets using the tap device. Some might say that doing this from inside the kernel is cheating, but given that the alternative was to copypaste the tuntap driver and edit it slightly, I call my approach constructive laziness.

The demo itself opens a TCP socket to port 80 on (IP address 0x43b484d1 if you want to be really precise), does a HTTP get for "/" and displays the last 500 bytes of the result. TCP/IP is handled by the rump kernel, not by the Linux kernel. Think of it as the Linux kernel having two alternative TCP/IP stacks. Again, a screenshot of the resulting dmesg is shown below. Note that unlike in the first screenshot, there is no printout for the root file system because the configuration used here does not include any file system support. Yes, you can ping

net demo screenshot

As hypothesized, a rump kernel hypervisor for the Linux kernel was easy and straightforward to implement. Furthermore, it could be done without making any changes to the existing hypercall interface thereby reinforcing the belief that unmodified NetBSD kernel drivers can run on top of most any embedded firmwares just by implementing a light hypervisor layer.

There were no challenges in the experiment, only annoyances. As Linux does not support rump kernels, I had to revert back to the archaic full OS approach to kernel development. The drawbacks of the full OS approach include for example suffering multi-second reboot cycles during iterative development. The other tangential issue that I spent a disproportionately large amount of time with was thinking about how releasing this code would affect existing NetBSD code due to GPL involvement. My conclusion was that this does not matter since all code used by the current demo is open source anyway, and if someone wants to use my code in a product, it is their problem, not mine.

For people interested in examining the implementation, I put the source code for the hypervisor along with the test code in a git repo here. The repository also contains the demos linked from this article. The NetBSD kernel drivers I used are available from or by getting and running ./ checkout.