FreeBSD on FreeBSD developer's notebook

Audio subsystem hardware internals

Thu, 30 Jul 2020 00:13:20 +0000

I wrote an introductory article on how the audio subsystem on SBCs work: CODECs, I²S, DTS, whole nine yards. WordPress editor didn’t seem to be a very convenient tool for this kind of write up so I gave asciidoc a try and so far liked it.

Link to the article: https://kernelnomicon.org/texts/sbc-audio.html

yubikey-agent on FreeBSD

Thu, 04 Jun 2020 00:03:01 +0000

Some time ago Filippo Valsorda wrote yubikey-agent, seamless SSH agent for YubiKeys. I really like YubiKeys and worked on the FreeBSD support for U2F in Chromium and pyu2f, getting yubikey-agent ported looked like an interesting project. It took some hacking to make it work but overall it wasn’t hard. Following is the roadmap on how to get it set up on FreeBSD. The actual details depend on your system (as you will see)

wpa_supplicant.conf "manager" for coffee shops

Tue, 12 May 2020 22:59:46 +0000

Whenever I sit down to work at the coffee shop I’ve never been before my preparation routine looks more or less like this: ifconfig wlan0 list scan, copy SSID, vim /etc/wpa_supplicant.conf, service netif restart. The WM I use, i3, does not have fancy network managers that nicely offer you to join available WiFi networks. It’s mildly annoying but not annoying enough to actually make me open a browser and go looking for ways to automate this procedure. Implementing such a utility, on the other hand, sounds like a nice weekend project.

Creating FreeBSD OVA files

Sun, 19 Jan 2020 16:13:17 +0000

If you want to jump right into the action check out freebsd-mkova repo. Below are some technical details on what OVA is and its internals.

In addition to installation media like DVD or memstick, FreeBSD RE ships FreeBSD releases as a virtual disk image in a number of formats. This is a convenient way when you start your whole VM using bhyve or qemu, as a single CLI command and pass the image location as an argument. It’s less handy if you try to create VM using GUI-based tools like VMWare or VirtualBox. You need to create VM and then configure it to use the image as a drive. Not an awful lot of work but still.

Audio for RK3399

Sat, 30 Nov 2019 19:46:08 +0000

Last two weeks I’ve been working on audio support for Firefly-RK3399. Full support requires a number of things that are not quite there or not available in the mainline FreeBSD kernel. The main low-level hardware functionality consists of two parts: I2S block in the SoC and RT5640 audiocodec that converts digital audio to an analog signal. They talk to each other using the I2S protocol. A little bit higher is FDT virtual “devices” called simple-audio-card. This part is responsible for coordinating the setup of both hardware components: make sure they agree on a number of channels, a number of bits per sample and clock specifics of the I2S protocol. There is no code for it in the FreeBSD kernel, so I had to just hardcode these things in both hardware drivers.

Color themes support^Whack for vt(4)

Sat, 19 Aug 2017 21:16:08 +0000

I was updating my laptop to the latest HEAD today and noticed that my bash prompt looks ugly in default console color scheme. So what with one thing and another I ended up writing color themes support for vt(4). Just because it was fun thing to do. The idea is that you can redefine any ANSI color in console using variable in /boot/loader.conf, i.e.:

kern.vt.color.0.rgb="0,0,0" # color 0 is black
# or
kern.vt.color.15.rgb="#ffffff" # color 15 is white

Here is how my Tomorrow Night theme looks like:

Minnowboard Turbot: GPIO, I2C, and SPI

Fri, 06 Jan 2017 14:35:33 +0000

Last year I got my hands on Minnowboard Turbot (courtesy of Frank H.) and spent some time working on communications protocols support for it. Below is short summary of what works and what doesn’t.

Minnowboard Turbot is Atom-base SoC, and standard x86 part (HDMI, network, USB) FreeBSD just works on it. The board has expansion connector that exposes I2C, SPI, and GPIO pins and can be used to talk to peripheral devices. Short summary of header pins can be found on developer.microsoft.com.

Accessing I2C and SPI from userland

Sat, 17 Dec 2016 20:29:46 +0000

Over years I accumulated fair number of devices I have no real use for. I ordered them either on impulse, or to add couple of $$$ to the bill to get free delivery. So in order to get at least some value from those purchases I put together goofy demo using two of such devices: I2C temperature sensor breakout from Sparkfun and 128x32 SPI OLED display from Adafruit.

I wrote two libraries to talk to TMP102 (chip in which temp sensor is based) over I2C and to SSD1306(OLED display chip) over SPI and several demos simple enough to put together in one day but flashy enough to excite my inner child and bring fond memories of MSDOS days. The SPI chip requires this fix in kernel. Userland SPI API provides only very basic functionality but luckily it was enough to talk to SSD1306.

rfkill on Jetson TK1

Sun, 11 Dec 2016 13:50:42 +0000

If you’re trying to install half-sized mini-PCIe wifi card in Jetson TK1, be aware, that the board has rfkill feature that is enabled by default. rfkill is hardware or software controlled switch that enables/disables RF signal on the wifi card itself. In case of mini-PCIe it’s controlled by level on pin 20 of the card. On Jetson TK-1 that pin is connected to GPIO X.7 pin. So to enable wifi on the board you need to run something like:

Quest for SMP on Raspberry Pi 3, part II

Fri, 25 Nov 2016 15:47:14 +0000

Update (11/29/2016): DTB overlay no longer required. PSCI monitor will patch in-memory DTB to add psci node. Commit

Short version of how to get RPi3 with SMP support

Build GENERIC arm64 kernel for your image, not GENERIC-UP
Copy https://people.freebsd.org/~gonzo/arm/rpi3-smp/u-boot.bin and https://people.freebsd.org/~gonzo/arm/rpi3-smp/armstub8.bin to FAT partition on SD card.
Copy https://people.freebsd.org/~gonzo/arm/rpi3-smp/psci.dtbo to overlays directory on FAT partition
Edit config.txt: change value of device_tree_address and add psci overlay. These two lines should be there:

device_tree_address=0x4000

Reboot device. It should boot with all four cores enabled and reboot should work too.

Long version of what’s in those .bin/.dtbo files

Boot sequence for PSCI monitor on RPi3 looks like this:

Quest for SMP on Raspberry Pi 3

Thu, 24 Nov 2016 10:58:06 +0000

Getting SMP support for RPI3 took some time and was interesting learning experience. So I share bits of what I learned here.

FreeBSD/arm boot start on one CPU (called primary) the rest of CPUs are “on hold”. At some point in boot sequence non-primary CPUs are forced to call mpentry() function. The way CPU is forced to call mpentry is platform-dependent. RPi2 for instance passes mpentry and argument to VideoCore using mailbox interface and then VideoCore kicks ARM CPU in action. So most of SoC has their own implementation of platform_mp_start_ap platform API method.

MFC tracking web-tool

Sun, 16 Oct 2016 19:50:03 +0000

Next week I plan to do bunch of MFCs for ARM and evdev stuff and to make it less of an ordeal I made this tool to track what’s merged and what’s not: mfc.kernelnomicon.org. It provides basic functionality I thought I would need for this process:

Navigator for HEAD commits with visual representation of MFC state: “no mfc scheduled”, “ready for mfc”, “waiting for ‘mfc after’ date”, “merged”
Basic filtering: by author name, by two states: “waiting”, and “ready”
“MFC basket” - manage set of commits I would like to merge back in one go
Generate svn command and change log for selected “MFC basket”

Stack used: Django + Bootstrap3 + jQuery

Raspberry Pi support in HEAD

Fri, 14 Oct 2016 22:29:03 +0000

Raspberry Pi 3 limited support was committed to HEAD. Most of drivers should work with upstream dtb, RNG requires attention because callout mode seems to be broken and there is no IRQ in upstream device tree file. SMP is work in progress. There are some compatibility issue with VCHIQ driver due to some assumptions that are true only for ARM platform.

SD card layout is the same as for RPi and RPi2 but boot chain is different. All ARM64 supported by FreeBSD up to now used EFI as boot environment. RPi 3 has only VC firmware and whatever it can spin off, e.g. u-boot. So it seemed easier to enable EFI API in U-Boot instead of porting ubldr to arm64. There were some hiccups with netbooting, (see patch) but otherwise it was OK. U-Boot port and crochet config for Pi 3 should be committed “real soon”(tm).

64-bit U-Boot on Raspberry Pi 3

Sun, 09 Oct 2016 16:57:35 +0000

Short summary of couple of frustrating hours I spent trying to get my RPi3 netbooting:

U-Boot - 2016.09 raspberrypi/firmware/boot - ec63df146f454e8cab7080380f9138246d877013

armstub.bin, armstub7.bin, armstub8.bin - NOT REQUIRED. There are tens of google results mentioning these files along with some dd magic - they all obsolete. Aforementioned version of firmware does not require them. 64-bit mode is controlled by arm_control variable in config.txt (see below). If 64-bit mode requested default kernel name becomes kernel8.img, and kernel load address becomes 0x80000. U-Boot uses correct default load address so no need for any additional parameters or hacks.

Multitouch support on FT5406

Sat, 08 Oct 2016 11:54:47 +0000

Few weeks ago evdev support was finally committed to HEAD. Project started a part of SoC 2014 by Jakub Klama and then picked up, finished and submitted by Vladimir Kondratiev. It’s drop-in compatible with Linux API which means all you need to do is add #ifdef _FreeBSD around respective includes and existing code (if it’s otherwise cross-compatible with FreeBSD) should just work. Which is the case for Qt and to lesser extent for tslib. Hardware support is still moving target, FreeBSD has evdev-compatible drivers for USB keyboards, USB mice, TI’s AM33xx touchscreen controller and Raspberry Pi’s official touchscreen. Only the latter device supports multitouch and Vladimir submitted patch required to get it working. To my knowledge it’s the first multitouch touchscreen ever working on FreeBSD so I decided to record demo to save this moment for generations to come. Well, not really. Mostly to brag and to let people know that it’s possible and encourage them to make stuff and experiment with FreeBSD, ARM, and Qt.

VirtualBox Shared Folders: progress report

Mon, 12 Sep 2016 15:59:05 +0000

I spent Labor Day weekend laboring on VBox shared folders support for FreeBSD. It’s been some time since I worked on it last time so I had to refresh my memory first. Things have moved on since then - VBox in ports was updated to version 5, but fortunately Li-Wen synced up freebsd-vboxfs repo to the latest version. After three days of laid-back hacking I am glad to announce that following VOPs are kind of implemented (in no particular order): lookup, access, readdir, read, getattr, readlink, remove, rmdir, symlink, close, create, open, write. “Kind of implemented” means that I was able to mount directory, traverse it, read file, calculate md5 sums and compare with host’s md5sum, create/remove directories, unzip zip file, etc but I doubt it would survive stress-test. Locking is all wrong at the moment and read/write VOPs allocate buffers for every operation.

Jetson TK1, FreeBSD, and SSD

Fri, 19 Aug 2016 13:30:39 +0000

Looks like my attempt to cheap out on SSD for TK1 has backfired. I went for the cheapest SSD available in local store (Toshiba Q300) but when I tried to checkout FreeBSD sources to the drive I got bunch of WRITE_FPDMA_QUEUED timeouts and system locked up. The same thing happened when I tried to perform checkout on Linux. The drive itself was OK, it survived “svn co …/head” and dd when connected using USB-to-SATA adapter.

FreeBSD on Jetson TK1

Tue, 28 Jun 2016 13:33:41 +0000

I finally got around to BSDify my Jetson TK1. Here is short summary of what is involved. And to save you some scrolling here are artifacts obtained from whole ordeal: https://people.freebsd.org/~gonzo/arm/jetson-tk1/

U-Boot

First of all - my TK1 didn’t have U-Boot. Type of bootloader depends on the version of Linux4Tegra TK1 comes with. Mine had L4T R19, with some kind of “not u-boot” bootloader. My first attempt was to use tegrarcm tool, it uses libusb, so it’s possible to build it on FreeBSD with some elbow grease, but once I tried to run it - it gave me cryptic errors and USB is not my strong skill so I took low road and installed Ubuntu VM. For what is’s worth I got the same kind of error on Ubuntu.

bsdfb platform plugin merged to Qt dev branch

Mon, 13 Jun 2016 17:28:22 +0000

Few weeks back Ralf Nolden, who is *BSD champion in Qt community, urged me to clean-up and submit my Qt5-related projects to upstream and scfb platform plugin was picked as a test dummy. It took 12 iterations to get things right, along the way plugin was renamed to bsdfb, but eventually patch has been merged.

Next two candidates are bsdkeyboard and bsdsysmouse input plugins.

VirtualBox Shared Folders: One VOP at a Time

Sun, 12 Jun 2016 18:31:32 +0000

Two months ago I tried to setup dev environment using FreeBSD Vagrant box just to find out that FreeBSD does not support VirtualBox shared folders. After some googling I found Li-Wen Hsu’s github repository with some work in this area. Li-Wen and Will Andrews has already done major chunk of work: patches to VirtualBox build system, skeleton VFS driver, API to talk to hypervisor but hit a block with some implementation details in VirtualBox’s virtual-memory compatibility layer. Will provided very comprehensive analysis of the problem.

gpiokeys support committed

Fri, 20 May 2016 17:10:36 +0000

To those who do not track FreeBSD commit messages: I committed gpiokeys driver to -CURRENT as r299475. The driver is not enabled in any of the kernels but can be built as a loadable module.

For now it stays disconnected from main build because it breaks some MIPS kernel configs. Configs in question include “modules/gpio” as part of MODULES_OVERRIDE variable and since gpiokeys can be built only with FDT-enabled kernel the build fails.

Qt 5.6 is here and it runs on FreeBSD/Pi

Sun, 20 Mar 2016 13:11:32 +0000

Qt 5.6 is finally out so I thought I’d give it a spin on my Raspberry Pi. Previously I used cross-compilation but this time I thought I’d spend some time in trying to create ports Qt modules. There is Qt 5.5.1 in ports and it’s nicely split into sub-ports and most of gory details are hidden in bsd.qt.mk library. The problem with it is it’s highly coupled with Xorg stuff and I didn’t find easy way to squeeze non-desktop use cases into current infrastructure. So I just created new custom devel/qt56 port.

FreeBSD, BBB and 4DCAPE-43T

Sun, 04 Oct 2015 18:49:07 +0000

Short demo of FreeBSD running on Beaglebone Black with 4DCAPE-43T

https://www.youtube.com/watch?v=4Vn_L_UzQhc

I used vendor-provided am335x-boneblack-4dcape-43t.dts file to generate dtb, you can download compiled blob here. The system running on demo is gpiokeys branch of my git repo: . Patch against -head is here.

If you’re interested only in LCD screen - it’s supported by -head but you’ll need to either add device gpiobacklight to BEAGLEBONE kernel config or enable LCD backlight manually using gpioctl: gpioctl -f /dev/gpioc1 18 1. gpiokeys is somewhat more complex thing and still WIP, there are some pieces missing in HEAD I had to hack around to make them work. And I haven’t started research on touchscreen yet.

FDT overlays in FreeBSD

Fri, 24 Jul 2015 15:17:35 +0000

FDT overlay is an extension to FDT format that lets user to modify base FDT run-time: add new nodes, add new properties to existing nodes or modify existing properties. It’s useful when you have base board and some extension units like cape/shield for Pi/BBB or loadable FPGA logic for Zynq. I will not go into details you can find internals described on Adafruit or Raspberry Pi websites.

When dealing with overlays there are two options where to handle them: loader or kernel. Managing overlays at kernel level gives more flexibility but requires more related logic, e.g. re-init pinmux after applying overlay, re-run newbus probe/attach. On the other hand loader-level support is quite straightforward and involves nothing but DTB modifications and it’s a natural first step to adding FDT overlays to FreeBSD.

Qt5 for FreeBSD/Pi

Wed, 14 Jan 2015 20:26:55 +0000

Build SD card image using crochet-freebsd with option VideoCore enabled. Mount either SD card itself of image to build host

mount /dev/mmcsd0s2a /pi

Checkout Qt5 sources and patch them

cd /src
git clone git://gitorious.org/qt/qt5.git qt5
cd qt5
git checkout 5.4.0
MODULES=qtbase,qtdeclarative,qtgraphicaleffects,qtimageformats,qtquick1,qtquickcontrols,qtscript,qtsvg,qtxmlpatterns
./init-repository --module-subset=$MODULES

fetch -q -o - http://people.freebsd.org/~gonzo/arm/rpi/qt5-freebsd-pi.diff | patch -p1

Configure, build and install Qt5 to SD card

./configure -platform unsupported/freebsd-clang -no-openssl -opengl es2 -device freebsd-rasp-pi-clang -device-option CROSS_COMPILE=/usr/armv6-freebsd/usr/bin/ -sysroot /pi/ -no-gcc-sysroot -opensource -confirm-license -optimized-qmake -release -prefix /usr/local/Qt5 -no-pch -nomake tests -nomake examples -plugin-sql-sqlite

gmake -j `sysctl -n hw.ncpu`
sudo gmake install

You need BSD-specific plugins to enable mouse and keyboard input in EGLFS mode

Audio on Raspberry Pi

Fri, 09 Jan 2015 23:25:08 +0000

With stable VCHIQ driver next obvious target was to add VCHIQ-based audio support. So let me introduce to you: vchiq_audio, first take. It’s part of vchiq-freebsd repo so if you use Crochet to build SD card image just enable option VideoCore in config file and module will be automatically included.

From shell run kldload vchiq_audio and you’re good to do. I believe that audio output is picked up automatically by VideoCore so if you have HDMI connected it’s probably going to be HDMI. I do not have device to confirm this. Adding knob to control audio output (auto, headphones, HDMI) is on my ToDo list.

Update on FreeBSD/armv6 in QEMU

Sat, 29 Jun 2013 17:37:58 +0000

QEMU support in FreeBSD/armv6 regressed since I tried it last time few months back. Changes in FreeBSD kernel and in QEMU itself revealed bugs that were masked by previous behaviour.

In FreeBSD it was r248467: the way memory/IO resources are activated on FDT bus has been changed and it triggered bug in versatile_pci.c

The other issue is more complex. It seems that PCI IRQ routing in QEMU was out of sync with real hardware. So after commit 66a96d7018b9cbabb73c9b87b62a37e4cc46580a IRQ numbers assigned to PCI devices by FreeBSD kernel by default were invalid. Authors of QEMU eventually added compatibility knob to fall back to previous logic. So if you’re using QEMU 1.5 or later add this option to your command line:

Raspberry Pi console

Mon, 24 Jun 2013 18:47:32 +0000

Quick hint. If you did not disable “device sc” in kernel config all the message from kernel go to video console. But if something bad happened after kernel started and before framebuffer driver is activated all you’ll see would be “Kernel args: (null)” message on serial console which is not very helpful. So in order to debug this problem and have kernel boot messages on both monitor and serial port without recompiling kernel just add following line to /boot/loader.rc on SD card:

Work in Progress: LCD driver for AM335x evaluation module

Sun, 05 May 2013 17:25:57 +0000

I’m trying to wrap up some project I started working on quite some time ago and this is first chunk of clean-up.

Patchcontains:

Kernel config for AM335x EVM
dts file for AM335x EVM with TFT panel info
LCD controller driver with some functionality missing: only 24/32 bit depth and only TFT mode is supported
Really simple PWM driver. LCD backlight is controlled through eCAS submodule of PWMSS0 module.

I tested it only on evaluation module, although I think with proper panel/pinmux configuration it should work with BeagleBone’s LCD caps too. Parts missing: adjusting clock to proper pixel frequency, proper allocation of framebuffer memory.

FDT driver skeleton generator

Fri, 03 May 2013 11:20:14 +0000

Writing new driver for FDT-based device always involves several simple steps:

writing generic newbus driver skeleton
Checking for compatibility of node in probe routine
Allocate memory/IRQ resources in attach routine

I can’t say for other developers but I just copy existing driver, remove all device-specific stuff and rewrite generic stuff. Which is less time-consuming then writing it from scratch but time-consuming it is. Being huge fan of automation of any kind I decided to let computer do all this dumb work and leave creative part (copy-pasting registers definition from spec to code) to myself. the result is this script.

Netbooting ARM/MIPS devices: kinds of kernel and u-boot

Fri, 15 Feb 2013 16:33:58 +0000

U-Boot is a boot loader. Its task is to get kernel into memory and pass control to it. I will cover only parts of it related to netboot.

kernel or kernel.bin

But before we start loading something we need to know what to load. In previous post I mentioned that there are kernel, kernel.bin, and ubldr files. Let’s get into details. First of all: ubldr requires its own post. So there will be one more covering just ubldr. Now kernel and kernel.bin.

VCHIQ drivers work again

Sun, 13 Jan 2013 19:19:10 +0000

I synced both vchiq-freebsd and userland to latest and greatest.

As I mentioned earlier - OS compatibility shim was removed from upstream sources so I had to create Linux KPI implementation layer which turned out not that awful task because I managed to reuse a lot of code from Max Khon’s DAHDI port. I had to implement (in somewhat hackish fashion) kthread API, re-implement semaphores support using condvar and mutex in order to get _interruptible part of API working properly and create dumb implementation of rather small subset of Linux list.h API.

FreeBSD/armv6: what's new and exciting?

Sun, 30 Dec 2012 17:51:03 +0000

It’s been a while since last update on the project status so it might seem as there was no progress in this area. The reality is: there is a bunch of activities happening with various levels of success. So I decided to give kind of end-of-the-year round-up of ongoing projects, plans and obstacles ARM hackers face.

First of all we tried switching default cache type from write-through to write-back type. It should have increased performance but instead opened a can of worms. Memory corruption debugging led to L2 cache driver on Pandaboard, EHCI driver code and subsequently to busdma code. Whole process took quite a few days full of hair-pulling and nagging various people and ended up in committing USB fixes and Ian Lepore’s busdma patches. PL310 (L2 cache controller) driver is being tested at this very moment. Original issue (WB caches) still stands and postponed till next year.

Cross-compilation hiccups

Sat, 01 Dec 2012 14:01:36 +0000

Good news and bad news. Let’s start with good ones.

Daisuke Aoyama tracked down what causes “Unrecognized filesystem type” error with some SD cards. It is U-Boot using High Speed mode. Root cause is still unknown but as a workaround I just disabled HS mode for SD card in u-boot and updated freebsd-uboot-20121129.tar.gz. Or alternatively you can get uboot-nohs.img and use it to replace uboot.img on your SD card.

Bad news are: installworld for cross-compiled FreeBSD is broken unless you’re doing it on the latest HEAD. The reason is utility called mtree(8). It is used to ensure that target filesystem permissions and owners/groups are correct. Owners and groups are described as usernames and group names, not as numeric UIDs/GUIDs and mtree uses getpwXXX family of routines to convert names to numeric values. See the problem already? If new system user is added to latest HEAD and you use old trusty FreeBSD 9.0, there is no way mtree would know about this user. NetBSD solved this problem by introducing -N command-line option that lets you point mtree to the target system’s master.passwd and groups. So we need to port this feature to FreeBSD in order to get proper cross-compilation environment. And that’s my plan for next few days.

FreeBSD on Pi: more stuff

Thu, 29 Nov 2012 21:21:19 +0000

Long overdue update on how the things are going with FreeBSD on Raspberry Pi. We’ve made some good progress so far:

Hans Petter Selasky fixed low-speed interrupt endpoints problem which means we have working USB keyboard now
GPIO driver by Luiz Otavio O Souza. So now you can blink OK LED (gpioctl -f /dev/gpioc0 -t 16). Not the most productive activity though.
Kernel now obtains information about display resolution, memory layout, MAC address from firmware
Framebuffer/syscons support added
Some stability fixes for SDHCI/li> Initial port of VCHIQ interface (vchiq-freebsd)
Port of userland libraries (userland)

Overall stability and performance is still a problem, but it’s what we’re going to work on next.

Flyswatter JTAG and AVR32

Mon, 09 Aug 2010 04:21:00 +0000

Today I soldered AVR32 adapter for Flyswatter JTAG. Actually it’s very simple task - just connect respective pins and make common ground wire. No capacitors, resistors or MOSFETs. Idea was to make it nice and neat but having bought wrong breadboard and soldered first headers in a wrong place I just let it flow and here it is:

From aesthetics point of view suck, but it also works and it’s everything I need:

Minor OpenOCD fixes

Tue, 06 Jul 2010 03:00:00 +0000

Back from the land of GUI software. I have bought one more Flyswatter JTAG recently and now have two boards connected to my home box. Unfortunately both Flyswatters got the same USB serial number so stock openocd opens only the first device it stumbles upon. Here is small patch that adds ft2232_index command to OpenOCD FTDI driver that allows to point at specific device to open. Works only with libftdi. In the same directory you can find my configs for AR71XX-based RouterStation Pro and Portwell’s CAM-0010 device based on Octeon CN3010

Writing FreeBSD NIC driver

Fri, 19 Feb 2010 06:22:00 +0000

I’ve been through writing NIC driver 2.5 times. 0.5 was porting ADM5120 switch driver by Ruslan Ermilov and Vsevolod Lobko from NetBSD. The usual routine for this kind of thing is “take existing driver and rewrite it”, e.g. copy selected parts or remove unnecessary ones. So I decided that it would be nice to skip “remove” part of procedure next time.

All cards I had to deal with (“both” wouldn’t be that impressive here) had similar design save for registers layout and some quirks. I believe that vast majority of NICs have the same design to some extent: there are circular RX/TX rings of more or less similar structure, interrupt status/mask register, media settings registers, you name it. Not a rocket science.

projects/mips RIP

Mon, 11 Jan 2010 19:45:00 +0000

All changes from projects/mips has been merged to HEAD. Kudos go to imp@ for sieving through mergeinfo mess projects/mips has been.

FreeBSD/mips and LLVM

Fri, 08 Jan 2010 23:12:00 +0000

Good news: LLVM builds fine on RouterStation Pro with root mounted over NFS.

Bad news: it segfaults on some tests and when trying to build hello world application.

Stay tuned

ohloh and FreeBSD

Tue, 05 May 2009 20:37:00 +0000

ohloh seems to be unable to grind FreeBSD’s svn repo. I’ve been watching for its efforts for several days now and commits progress meter resets from time to time:

https://www.ohloh.net/p/freebsd/enlistments

singleuser on routerstation

Fri, 01 May 2009 05:23:00 +0000

http://people.freebsd.org/~gonzo/mips/routerstation.log

Some issues still pending though. Cache management is major one. Things seemed to work fine in emulation but backfired into face with real hardware. I ran into several “random” bugs that were narrowed down to caches. More to go :( Also ethernet driver performance is low but it’s easier then hunting down ethereal cache matters. Or so I think.

This weekend will be dedicated to making openocd work with routerstation, learning debugging and profiling techniques for MIPS hardware and improving FreeBSD/MIPS pieces of DDB.

JTAG, OpenOCD & FreeBSD

Sun, 19 Apr 2009 18:51:00 +0000

As it was mentioned earlier now I have new cool toy to play with. Flyswatter JTAG with MIPS14 adapter. Though Tin Can Tools kindly warned me that OpenOCD did not support EJTAG/MIPS I decided to order it and it turned to be a good deal. Why? Because there is EJTAG/MIPS support for OpenOCD as of 0.1.0. Moreover it works really nice with FreeBSD port of libftdi. So all I had to do was to make devel/openocd port and tweak some configs. And that’s it. Stock gdb for MIPS is not ready yet, but one can attach, examine registers, single step using telnet interface to daemon:

svk & vim

Fri, 10 Apr 2009 16:45:00 +0000

My SCM of choice for FreeBSD-related projects is SVK (it’s much faster then subversion and provides offline access to repo history, easy branching/merging and so on). And my editor of choice is vim. And it turns out vim doesn’t highlight svk commit files. What a shame. No bright colors for happy hacker who is about to commit clean and robust code (or break buildworld, whatever). So I spent 20 minutes of tweaking svn.vim and produced this.

WIP: Ubiquity's router station

Thu, 26 Feb 2009 21:30:00 +0000

So it has been a month since last post about this device and I think it’s time to announce current state of affairs.

At the moment further progress was blocked with something that looks like memory corruption. It’s hard to trace with ktr(4) and printf(9) so I ordered Flyswatter JTAG adapter and MIPS14 adapter from Tin Can Tools. I was warned that Flyswatter/MIPS combination is not supported by OpenOCD but I’d better spend some time making it work then tracing obscure memory corruptions in the wild.

Thinkpad T400 and FreeBSD

Thu, 22 Jan 2009 01:12:00 +0000

Finally I got my hands on new and shiny Lenovo Thinkpad T400. What can I say? It’s cool. My only complaint about T60 was its somewhat dim display (yes, I tried to save some money on this vital part and got punished). This time I ordered model with LED backlight and it’s worth every dime spent :)

My configuration also included Atheros wifi, built-in bluetooth, Intel GMA X4500 graphics (I’m not in games, really). Unfortunately 7.1 was able to run wifi. Newer HAL did the trick though and here I am: eating my own dog food - running -CURRENT on a workhorse.

The Joy of Bugbusting

Wed, 11 Jun 2008 14:11:00 +0000

While waiting for MIPS toolchain import to happen I entertain myself with bugbusting. You should try it sometime. GNATS jungle, small and large bugs are sneaking around, scent of rotten emails in the air. I don’t feel like hunting down large bugs. They’re dangerous beasts. It’s much better to deal with small ones. Pick a (one|two|three|up-to-twenty)-liner and fix it. Then you can bring it home, varnish it and eventually MFC it. Nice outdoor activity for developers :)

bsddev blog SitRep

Thu, 29 May 2008 14:36:00 +0000

Long time no blog. Many things have happened during last 6 months: I got a commit bit, FreeBSD/MIPS reached multiuser and started migration from P4 to CVS. Right now we’re waiting for toolchain patches to be imported to contrib/binutils properly. So let’s prepare to celebrate buildable FreeBSD/MIPS world in a couple of weeks! Meanwhile I’m busy with getting latest zaptel (they changed name to DAHDI, actually) drivers to FreeBSD and a couple of side aсtivities like digging into aio code from OpenSolaris/Linux/FreeBSD. Hope to blog more regularly now. Stay tuned.

NY gift from Juniper

Fri, 28 Dec 2007 14:57:00 +0000

Juniper released FreeBSD/MIPS port to public. There are no references to JNPR-specific hardware pieces but a lot of mature code for generic MIPS devices that mips2 tree lacks: VM/pmap, libc, FPU support. Nice gift, thanks JNPR!

RB532 progress

Sun, 09 Dec 2007 19:37:00 +0000

This weekend I spent writing driver for IDT RC32434 on-board Ethernet adapter. Weird hobby, isn’t it? Writing NIC drivers is new to me so I shared my time between reading if_XX sources, reading IDT specs and writing my own code. Task turned out easier then it appeared and 15 minutes ago I managed to mount root over NFS using kr0 interface. Time to get some beer and celebrate!

Mikrotik RB532 - single user mode.

Sat, 01 Dec 2007 23:38:00 +0000

Today I managed to get shell prompt on Mikrotik’s Routerboard 532. So now we have 3 platforms with single user mode for FreeBSD/mips, not very useful :) The last problem was getting high-level console interface working. I always fell lost when it comes to resource allocation and uart stuff. I should write a couple of posts on these subjects to memorize all details better.

INTR_FAST and selwakeup

Sun, 25 Nov 2007 13:22:00 +0000

I stumbled over this problem a couple of years ago, ignored it, was punished for my carelessness, came out with hackerish solution and now I know “The Right Way” to solve this issue. So, the headache starts when you’re trying to wakeup userland application polling on a descriptor from INTR_FAST IRQ handler (for 7.X and later that would be interrupt filter). INTR_FAST/interrupt filter routines are usually used for timing-critical tasks and run in IRQ dispatcher context, so no operations that may cause context switch are allowed in this code. Unfortunately selwakeup(9) tries to acquire sellock that leads to a possible context switch and leaves us in a total mess. My solution was handmade kernel thread that has been running through list of channels and performed all dirty work, not the cleanest and easiest to maintain code. “Zaptel-bsd take 2” utilizes taskqueue(9) interface to work around IRQ handler limitations. There is handler routine:

Module/kernel parameters

Tue, 20 Nov 2007 20:58:00 +0000

Sometimes it’s desirable to pass some arguments to module to customize its behavior, e.g.: to set/unset verbosity level of debug output, set operation mode etc… Linux modules can get this information from insmod utility, but kldload is not capable of doing such kind of things. What a pity. But don’t get desperate - tunables to the rescue!

Just like an ordinary command shell (bash, csh, sh) kernel has its own environment, the set of <name, value> pairs. You can get, set, test, unset these variables using getenv, setenv, testenv, unsetenv functions in the kernel and kenv(2) syscall or kenv(1) command in userland. So if you want to set verbosity level for module, you would do something like this: