OS X: Flyswatter, JTAG & RS232

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

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

Tasting Cocoa

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?

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

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

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

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

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

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

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

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

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

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

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.