FreeBSD developer's notebook

Flyswatter JTAG and AVR32

2010-08-08T21:21:00.005-07:00

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:

Info : JTAG tap: avr32.cpu tap/device found: 0x21e8203f (mfg: 0x01f, part: 0x1e82, ver: 0x2)

Warn : JTAG tap: avr32.cpu UNEXPECTED: 0x21e8203f (mfg: 0x01f, part: 0x1e82, ver: 0x2)

Minor OpenOCD fixes

2010-07-05T20:00:00.003-07:00

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

2010-02-18T22:22:00.002-08:00

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.

So I took if_arge driver from Atheros AR71XX SoC and replaced hardware-dependent parts with FIXME comments. Also string "ARGE" was replaced to "ADAPTER" and "arge" to "adapter" so simple s/adapter/xyz/g and s/ADAPTER/XYZ/g would give us a half-baked source base for if_xyz driver.

It's yet to be tested whether this approach would be of any good. I'm planning to try it in next few days :) Meanwhile you can check sources here.

FReeBSD/MIPS & clang/LLVM

2010-01-18T13:49:00.004-08:00

Now I know a little bit more about clang. I can't say it's quite useful for MIPS yet, but it's nice to see some progress in this field. My findings might be inaccurate and any corrections are welcome.

- No proper cross-compilation so far. Clang team plans to do it "right way" but so far it's just an item on their ToDo list: Universal driver. There are command-line options like -ccc-host-triple to get target assembler code, but names for assembler/linker are hardcoded to as/ld, which puts some restriction on building target toolchain

UPD: -ccc-host-triple does the trick OK

- No proper march/mabi handlers for MIPS platform. Only ARM and x86 are supported.

I managed to build hello world application in semi-automatic mode on RouterStation booted over NFS:

[root@ /llvm/llvm]# clang -v -fPIC -Wa,-mabi=32,-EB,-KPIC hello.c
clang version 1.1 (trunk)
Target: mips-unknown-freebsd9.0
Thread model: posix
"/opt/bin/clang" -cc1 -triple mips-unknown-freebsd9.0 -S -disable-free -main-file-name hello.c -pic-level 2 -mdisable-fp-elim -v -resource-dir /opt/lib/clang/1.1 -fmessage-length 0 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-tuAxTl.s -x c hello.c
clang -cc1 version 1.1 based upon llvm 2.7svn hosted on mips-unknown-freebsd9.0
#include "..." search starts here:
#include <...> search starts here:
/opt/lib/clang/1.1/include
/usr/local/include
/usr/include
End of search list.
"/usr/bin/as" -mabi=32 -EB -KPIC -o /tmp/cc-LZzHnl.o /tmp/cc-tuAxTl.s
"/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 -o a.out /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o /tmp/cc-LZzHnl.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o
[root@ /llvm/llvm]# ./a.out
Hello world!
[root@ /llvm/llvm]# uname -a
FreeBSD 9.0-CURRENT FreeBSD 9.0-CURRENT #28: Fri Jan 15 16:50:23 PST 2010 gonzo@figaro.bluezbox.com:/src/FreeBSD/obj/head-mips/mips/src/FreeBSD/head/sys/AR71XX mips
[root@ /llvm/llvm]#

So it seems to be nice starting point for some minor compiler hacking :)

projects/mips RIP

2010-01-11T11:45:00.002-08:00

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

2010-01-08T15:12:00.002-08:00

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

OS X: Flyswatter, JTAG & RS232

2009-11-23T11:33:00.004-08:00

Since I lent my RS232/USB adapter to a friend it was nice opportunity to experiment with Flyswatter on-board RS232 port. OS X does not support FTDI devices out of the box, but it's not a problem for OpenOCD, which uses generic interface to communicate JTAG board. Things get a little bit more complicated when you're trying to get on-board RS232 port working.

I started with installing stock drivers from FTDI site. Current version supports Snow Leopard. With these drivers installed system started to detect two COM ports but JTAG part stopped to work as OpenOCD failed to claim USB device.

Long story short: you'll need to edit kext content to prevent first usb device from being recognized as a virtual COM port. Nothing fancy, simple text editor would do the trick for all you need to edit is plain XML file. Find line <key>FT2232C_A</key> and delete it along with following <dict> element. Reload kext using kextunload/kextload and voila - JTAG works, "cu -s 115200 -l cu.usbserial-FS000000B" works.

OS X 10.6.2

2009-11-10T14:49:00.002-08:00

MBP started overheating after this update. PRAM resetting, as google suggested, helped. No other significant damages detected.

Tasting Cocoa

2009-08-10T00:31:00.004-07:00

The best way to learn new technology is to use it. Here is a small project I've put together while learning Mac OS X/Cocoa development: AudioBookBinder, may be someone will find it useful. This utility takes collection of mp3 files (or any other audio format recognizable by OS X) and binds it to one audiobook(m4b file) suitable for listening on iPod. The initial idea was to make it a GUI app, but I've been spoiled with command line power for too long.

Is it self-hosted yet?

2009-07-08T10:18:00.004-07:00

Good news everyone! Last two days I've been testing FreeBSD/mips by running buildworld on netbooted RouterStation with root mounted over NFS. So far so good, it successfully completed twice.

A couple of weeks ago arch-dependent part of libthr (both kernel and userland) was implemented and it seems to work. "Seems to work" means that it passes thr1 and thr2 tests from stress2 and python's test_thread[ing].py. And yes, python and perl build fine on the same board from the ports do work. As bash et al :) Though perl should be built without Perl malloc but it's on my ToDo list.

vim & xcodebuild

2009-05-06T16:12:00.003-07:00

Small hint to those rare birds who (like me) want to work on his Xcode projects over ssh connection and uses vim for this purpose. Usually I use quickfix mode but there is no compiler file for Xcode in vim distribution. Luckily there is obsolete pbx.vim (compiler file for Apple Project Builder, predecessor of Xcode) that could be easily converted to support modern tools. Of course, writing xcode.vim from scratch would take only a couple of minutes but who wants to make it manually if it's possible to automate this process?

Here is magic command:

cat /usr/share/vim/vim72/compiler/pbx.vim | sed s/pbx/xcode/g > /usr/share/vim/vim72/compiler/xcode.vim

Stay tuned. Next week I'll teach you how to control Death Star with simple perl script.

ohloh and FreeBSD

2009-05-05T13:37:00.002-07:00

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

2009-04-30T22:23:00.002-07:00

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.

More on OpenOCD and MIPS/EJTAG

2009-04-27T15:36:00.005-07:00

Well, I was overly optimistic. OpenOCD can halt CPU, reset, examine registers and perform software breakpoints. Trying to figure out what's wrong with EJTAG support I skimmed the code and the state of it is, well, poor. Current implementation assumes that target is of the same endianness as host. That's why number of HW breakpoints/watchpoints was detected wrong. But even fixing (endianness and breakpoints) and implementing(watchpoints) in hack'n'slash mode didn't help. I still can't get bp/wp to work. But I'll definitely try. May be next weekend.

JTAG, OpenOCD & FreeBSD

2009-04-19T11:51:00.007-07:00

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:

[gonzo@figaro:][~/FreeBSD]
% telnet localhost 4444
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> halt
target state: halted
target halted due to debug-request, pc: 0x8023b974

> reg
(0) zero (/32): 0x00000000 (dirty: 0, valid: 1)
(1) at (/32): 0x802c0000 (dirty: 0, valid: 1)
(2) v0 (/32): 0x00000001 (dirty: 0, valid: 1)
(3) v1 (/32): 0x00000000 (dirty: 0, valid: 1)
(4) a0 (/32): 0x00000000 (dirty: 0, valid: 1)
(5) a1 (/32): 0x00000000 (dirty: 0, valid: 1)
(6) a2 (/32): 0x80280b28 (dirty: 0, valid: 1)
(7) a3 (/32): 0x00000602 (dirty: 0, valid: 1)
(8) t0 (/32): 0x802c10b0 (dirty: 0, valid: 1)
(9) t1 (/32): 0x00000000 (dirty: 0, valid: 1)
(10) t2 (/32): 0x00000000 (dirty: 0, valid: 1)
(11) t3 (/32): 0x00000000 (dirty: 0, valid: 1)
(12) t4 (/32): 0x00000000 (dirty: 0, valid: 1)
(13) t5 (/32): 0x00000001 (dirty: 0, valid: 1)
(14) t6 (/32): 0x00000000 (dirty: 0, valid: 1)
(15) t7 (/32): 0x00000000 (dirty: 0, valid: 1)
(16) s0 (/32): 0xc082abe0 (dirty: 0, valid: 1)
(17) s1 (/32): 0x801312a8 (dirty: 0, valid: 1)
(18) s2 (/32): 0x00000000 (dirty: 0, valid: 1)
(19) s3 (/32): 0xc0828b20 (dirty: 0, valid: 1)
(20) s4 (/32): 0xc0793ea0 (dirty: 0, valid: 1)
(21) s5 (/32): 0x00000000 (dirty: 0, valid: 1)
(22) s6 (/32): 0x00000000 (dirty: 0, valid: 1)
(23) s7 (/32): 0x00000000 (dirty: 0, valid: 1)
(24) t8 (/32): 0x02887fa0 (dirty: 0, valid: 1)
(25) t9 (/32): 0x00000002 (dirty: 0, valid: 1)
(26) k0 (/32): 0x8024e3a0 (dirty: 0, valid: 1)
(27) k1 (/32): 0x00000000 (dirty: 0, valid: 1)
(28) gp (/32): 0x00000000 (dirty: 0, valid: 1)
(29) sp (/32): 0xc0793e30 (dirty: 0, valid: 1)
(30) fp (/32): 0x00000000 (dirty: 0, valid: 1)
(31) ra (/32): 0x8023b964 (dirty: 0, valid: 1)
(32) status (/32): 0x0000ff01 (dirty: 0, valid: 1)
(33) lo (/32): 0x0000001c (dirty: 0, valid: 1)
(34) hi (/32): 0x00000020 (dirty: 0, valid: 1)
(35) badvaddr (/32): 0xc0797dc8 (dirty: 0, valid: 1)
(36) cause (/32): 0x40008000 (dirty: 0, valid: 1)
(37) pc (/32): 0x8023b974 (dirty: 0, valid: 1)
>

svk & vim

2009-04-10T09:45:00.001-07:00

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.

It's a syntax file for svk-commit* and two functions to place file under/out of SVK control (just like in perforce one can tweak commit file to select which files will be committed and which won't).

WIP: Ubiquity's router station

2009-02-26T13:30:00.005-08:00

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

UART: just works
PCI controller: kind of works. Proper interrupt handling/routing required.
On-board ethernet controller: WAN port works fine. Mounts NFS root/loads init. Some minor work should be done in order to get both ports working.
Integrated OHCI controller: kernel detects and initializes it. Need USB cable to connect something to headers on the board and test if it actually works.
Integrated EHCI controller: in progress. Some refactoring of current MIPS bus_space implementation required.
GPIO: to be done
Flash memory: to be done

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.

Scheduled for reading

2009-02-23T16:33:00.011-08:00

Has just received two books from Amazon.

The first one is Beautiful Architecture by fellow FreeBSD developer Diomidis Spinellis and Georgios Gousios. I bought it because software design is not my strongest skill and there is a lot of place for improvement. And learning from real life examples is always better then reading pure theory.

The other one is The Productive Programmer by David Bock. Productivity is my sweet spot (well, it's more about cool tips then real productivity boost). This had nice reviews so I decided to give it a try.

FreeBSD/mips: what's cooking

2009-01-26T13:46:00.004-08:00

In last two months I've got two new toys: WGT634U from bms@ and Ubiquity Networks' Router Station 2 provided by manufacturer. The first one is Broadcom's Sentry5 based and the second one is built on Atheros' AR7100 chip. As AR7100 is more advanced technology (and has less obscure design, at least it seams less obscure to me) I decided to pick up this low hanging fruit. So far so good: kernel boots, PCI bridge detects Atheros miniPCI wireless card. GigE driver is on its way.

Thinkpad T400 and FreeBSD

2009-01-21T17:12:00.002-08:00

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.

Intel graphics was kind of disappointment. I expected no problems with this integrated chipset but there were a lot. "Ghost" video output (or companion display) that was causing mplayer not to run in fullscreen mode (fixed with xrandr). With SWCursor option off text console is garbled when switching to it from X. mplayer is somewhat laggish in full screen mode :( I hope intel driver will be updated soon, meanwhile I'll refrain from watching movies (it should boost my productivity :))

UPD: It seems that Intel Video artifacts is due to unsymmetrical memory layout (I have 2G + 1G). Windows 7 is affected as well.

FreeBSD/MIPS: something lost, something gained

2008-11-03T20:01:00.005-08:00

And again long pause in blogging. In this 4 months several things happened to me: I relocated to Vancouver, was interviewed and rejected by Microsoft (don't know why they contacted me in the first place), met new people (philip@ and thompa@ among them), saw new places and even got some free time and learned to cook (it turned out to be fun!).

Being close(geographically) to PMC-Sierra, major MIPS vendor, I tried to contact them and ask for a donation for FreeBSD/MIPS project. Got no reply, though. Predictable result, but it's better to try and fail then have never try at all.

Relocations is ideal way to get rid of garbage that has been accumulated through years. Unfortunately Mikrotik RB532, ADM5120-based Edimax device and Linksys WRT54GL were in the "garbage" I had to left. So it's kind of a loss. But life without wireless AP is miserable (don't blame me, I'm just a geek) so new and shiny Linksys wrt160n was bought from nearest Future Shop. And I even managed to solder serial console to it. And it works. I'm really bad with soldering iron so it's something I'm going to be proud of for the next two years. By the way the process has been documented.

Though it took some efforts FreeBSD was successfully booted on it! Well, sort of successfully. But I'm making progress and going to keep you informed! Stay tuned!

The Joy of Bugbusting

2008-06-11T07:11:00.002-07:00

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 :)
PS
The first PR I've nailed: kern/123685.

bsddev blog SitRep

2008-05-29T07:36:00.004-07:00

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

2007-12-28T06:57:00.000-08:00

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

2007-12-09T11:37:00.000-08:00

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.

2007-12-01T15:38:00.000-08:00

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

2007-11-25T05:22:00.000-08:00

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:


static void 
handle_selwakeup(void *context, int pending) 
{
    struct selinfo *sel = context;
    selwakeup(sel);
}

then selinfo/task structures for every channel:


...
    /* thingy for select stuff */
    struct selinfo  sel;    
    struct task     selwakup_task;
...

which should be initialized during channel allocation:


...
    TASK_INIT(&chan->selwakup_task, 0, 
        handle_selwakeup, &chan->sel);
...

and used anytime we'd like to call selwakeup:


...
    taskqueue_enqueue_fast(taskqueue_fast, 
        &timer->selwakup_task);
...

Module/kernel parameters

2007-11-20T12:58:00.000-08:00

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:


    # kenv zaptel.debug=1
    # kldload ./zaptel.ko

and then in module initialization routine:


    static int debug = 0; /* Hush-hush */
    ...
    char * value = getenv("zaptel.debug");
    if (value) {
        debug = strtol(value, NULL, 10);
        freeenv(value);
    }

Too much code for such a simple task, don't you think? Yeah, like for every common task there are useful macroses defined in kernel headers, you should just find them. Heavy coffeinated kernel hackers knew most of them. In this particular case neat code would look something like that (for statically initialized variable):


    static int debug = 0; /* Hush-hush */
    TUNABLE_INT("zaptel.debug", &debug);

or, if debug is the member of structure or local variable:


    sc->debug = 0;
    TUNABLE_INT_FETCH("zaptel.debug", &sc->debug);

TUNABLE_XXX macroses exist for INT, LONG, ULONG and STR types. TUNABLE_STR unlike the others requires third parameter - maximum size of the string. For a dynamic value retrieval every type has TUNABLE_XXX_FETCH macro defined. Nota bene: if there is no environent variable set with requested name, the value of acceptor variable remains untouched.

Introduction

2007-10-29T14:04:00.000-07:00

Hello. My name is Oleksandr Tymoshenko. I'm a software developer. My involvement in FreeBSD project started in 1998 by making static entries in ARP table really static. Though patch hasn't made out of my university's network it was "the beginning of a beautiful friendship". My first significant contribution to FreeBSD community (or so I'd like to think) was porting of Zaptel drivers from Linux to FreeBSD. About two years ago I happened to work with a MIPS board and got some interest to the architecture. Since then I've been doing my best trying to bring FreeBSD to this platform and, actually, succeeded to some extent with a help from developers crowd.

In this blog I'm going to make notes on drivers development and porting process. Mostly for myself - to memorize gotchas and pitfalls which happen from time to time. But I hope that these notes will be of some use to other kernel hacker wannabes.