Showing posts with label FreeBSD. Show all posts
Showing posts with label FreeBSD. Show all posts

Sunday, August 8, 2010

Flyswatter JTAG and AVR32

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)

Monday, July 5, 2010

Minor OpenOCD fixes

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

Thursday, February 18, 2010

Writing FreeBSD NIC driver

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.

Monday, January 11, 2010

projects/mips RIP

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

Friday, January 8, 2010

FreeBSD/mips and LLVM

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

Tuesday, May 5, 2009

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

Thursday, April 30, 2009

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.

Sunday, April 19, 2009

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)
>

Friday, April 10, 2009

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).

Thursday, February 26, 2009

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.

Wednesday, January 21, 2009

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.

Wednesday, June 11, 2008

The Joy of Bugbusting

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.

Thursday, May 29, 2008

bsddev blog SitRep

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.

Friday, December 28, 2007

NY gift from Juniper

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!

Sunday, December 9, 2007

RB532 progress

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!

Saturday, December 1, 2007

Mikrotik RB532 - single user mode.

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.

Sunday, November 25, 2007

INTR_FAST and selwakeup

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);
...

Tuesday, November 20, 2007

Module/kernel parameters

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.