I just had a very quick look into what could be done to fix the FET430 UIF firmware loading issue I wrote about before. The issue looks like it was fixed in this commit. That’s in Linux 2.6.29, which was released 6 days ago.
No work for me to do there then…
I wanted to always be able to shell to a machine within the Uni network. The Uni network has a firewall that stops incoming requests to most machines. There’s a machine that all undergrads can shell to, which I normally use netcat combined with the ssh ProxyCommand setting. However, it’s a little silly to divert all traffic through another machine when I’m in the network. So, meet the new script I use in the ProxyCommand:
#!/bin/bash
HOST=$1
got=`ifconfig eth1 | egrep -o "inet addr:152.78.[0-9]{1,3}\\.[0-9]{1,3}"`
got+=`ifconfig eth0 | egrep -o "inet addr:152.78.[0-9]{1,3}\\.[0-9]{1,3}"`
if [[ "$got" == "" ]]
then
ssh uglogin.ecs.soton.ac.uk nc $HOST 22
else
nc $HOST 22
fi
I spent today working on a bug in the driver for the TI UIF MSP430 programmer. It stopped initialising properly in 2.6.24, but it worked in 2.6.23. I did a git-bisect between those versions to find the commit that induced the fault. I narrowed the search a bit by telling git-bisect to work on commits only in drivers/usb/, as I hypothesized that the bug was induced somewhere in there.
About 10 builds and 20 reboots later, I found the commit in which the problem was happening, and then read some stuff about USB etc (the LWN device drivers book proved invaluable yet again) and subsequently generated a patch. I’ve sent it to (what I think are) the right places.
If you can’t wait for the next kernel release (if it passes review…), then you can rebuild the ti_usb_3410_5052 module by downloading this tarball, untarring it and then running “make” in the resulting directory, and then “make install” as root. You will need enough of your kernel’s sources hanging around to do this. In Fedora, these are provided in the kernel-devel package.
Update (5th April ‘08): The patch has made its way into Linus’s tree, so I think it’ll be in 2.6.25.
I downloaded the Fedora Alpha 9 live CD ISO and ran it on my desktop. It’s got PolicyKit and PackageKit, which are pretty cool. Just after I’d logged in, I was greeted with this box:
I clicked “Yes” (I’d click “always”, but this was on a Live CD so it wouldn’t really have meaning), and then it popped up with:
Pretty cool. It didn’t ask me for any of my details, which I think is cool. Going to kerneloops.org reveals that it exists to track which crash signatures occur the most.
I walked to the shops earlier. I took my mp3 player with me, which I haven’t used in a while. I keep all local copies of my (new) music in Ogg Vorbis or FLAC, which means that when I transfer to my mp3 player, I have to convert the tracks. Previously, I’ve bashed together a shell script that does the conversion, but today was different. Today I got graphical.
I had a quick search for audio converters for GNOME, and found AudioFormat and audio-convert-mod. audio-convert-mod is in the Fedora repos, so I used that. It was surprisingly enjoyable. It automatically detected the encoders and decoders that were available on my system:
The program takes the form of a wizard, which first asks for the files to convert, then the format to convert to, and the destination directory. Then it converts them. That’s it, no hassle.
R.
I sent my “sendkey” script to Ivor. This script automates the injection of one’s ssh public key into a remote host’s authorized_keys file (to allow password-less login). It didn’t work very well when Ivor ran it. I’ve now updated the script:
#!/bin/bash KEY=`cat ~/.ssh/id_rsa.pub` ssh $1 bash <<EOF mkdir -p ~/.ssh chmod u=rwx,g=,o= ~/.ssh echo $KEY >> ~/.ssh/authorized_keys chmod u=rw,g=,o= ~/.ssh/authorized_keys EOF
It can be run like this:
% ./sendkey remoteusername@remotehost
15/02/2007 Update: I fixed the script so that it made the .ssh directory first… kind of important.
29/02/2007 Update: Klaus pointed out that it might be useful to write how to generate one’s ssh keys:
/usr/bin/ssh-keygen -t rsa -f ~/.ssh/id_rsa -N ''
I just wrote a udev rule that would make any userspace i2c devices be owned by the i2c group:
KERNEL=="i2c-[0-9]*", GROUP="i2c"
(You can stick that in a file in /etc/udev/rules.d if you’re using Fedora).
Recently I needed to log the calls to read() and write() calls that a program made, including the data that went through them. I hacked together a small program, called “iomon”. It runs on Linux (or at least on my Fedora 8 install anyway). What makes it exciting is that I can use it without modifying the program I’m monitoring.
It uses features of the dynamic linker (the thing that’s resposible for loading the shared libraries that a program needs during execution – see man ld.so) to interpose a monitoring function between a call to a library function and the actual library function. When read(), write() or open() are called, an event is logged.
You can get iomon by checking it out like so:
git clone http://xgoat.com/proj/fiu/iomon/iomon.git/
You can build it by just running “make”:
% cd iomon % make
You might need to install the glib 2.0 headers (in Fedora, they’re in the glib2-devel package).
Example Usage
I thought it might be useful to demonstrate how to use it with an example. After building iomon, build the following C program (also available here) using gcc:
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>
int main( int argc, char** argv )
{
int f, g;
umask( 000 );
f = open("test-file1", O_RDWR | O_CREAT);
g = open("test-file2", O_RDWR | O_CREAT);
write(f, "test", 4);
write(g, "second file", 11);
return 0;
}
This is the program that we’re going to monitor. As you can probably see, the program just opens a file called “test-file1″ and another called “test-file2″. It then writes “test” and “second file” to the first and second file respectively. Not really a very useful program, but it will suffice for this demo.
The next thing to do is set the LD_PRELOAD environment variable to contain iomon.so. The dynamic linker needs to be able to find the shared object file, and so the easiest thing to do is to put the full path into LD_PRELOAD:
% cd iomon % export LD_PRELOAD=`pwd`/iomon.so
Now every time that you run a program in this shell, iomon.so will be loaded first. At the moment iomon will default to dumping all the read, write and open calls to standard output in raw format. I suggest that you don’t run anything in this mode… iomon is configured through the IOMON environment variable. This takes a list of arguments just like any command line program:
% IOMON="--help" cat /dev/null Usage: iomon [OPTION...] iomon Help Options: -?, --help Show help options Application Options: -f, --file File to monitor access to. -l, --log Log file -t, --text-log Log in text, instead of binary --times Include times in the log
There’s some helpful information on how to use it. I’ll explain the arguments in a little more detail:
- -f FILE, --file FILE
Instead of logging all file access, just log access to FILE. iomon will monitor calls to open() to get the file descriptor assigned to FILE, and will only log calls to read() and write() that use that file descriptor. At the moment, iomon only supports one file descriptor per file (patches welcome!). - -l FILE, --log FILE
Send log output to FILE, rather than standard output. - -t --text-log
This makes the log human-readable. All data is converted into readable hex strings before writing to the log file. - --times
Prepend every log event with a timestamp. The timestamps are relative to the first interposed function call. Only implemented for text-based output (--text-log)
Right! Now we can run the test program:
% IOMON="-t --times -f test-file2" ./test 0.000016 open: 74 65 73 74 2D 66 69 6C 65 32 0.000138 write: 73 65 63 6F 6E 64 20 66 69 6C 65
And there we see the call to open for test-file2, followed by the filename in hex. Then there’s the data sent to it through write() also in hex. The logged call to open() happened 16μs after the first call to open(), and the write() call we were interested in happened 122μs later.
Hopefully I’ll be writing about why I needed this utility later.
I’ve been using various I2C things in Linux for the past year and a bit, and I’ve learnt a few things about it from that. Here I hope to collate some of this information.
Since our robotics kit uses an I2C bus, it would be really handy for me to have a USB-to-I2C adapter. With the addition of a simple RJ11 adapter, I’d be able just plug in a module and start hacking on it without the annoying set-up times, that involve sorting out the Slug and power board combo. If Student Robotics had several of these adapters, then any member could just grab a module and start hacking on some code.
i2c-tiny-usb:
I’ve just come across Till Harbaum’s i2c-tiny-usb design. Rather surprisingly this uses a relatively cheap ATtiny45 Atmel AVR and nothing else. It bitbangs the USB protocol. Apparently, this works rather well. What’s even more exciting, is that there’s a kernel driver available for the i2c-tiny-usb. This makes it behave as a proper Linux i2c bus device, so interacting with it from software couldn’t be simpler. This board can be an I2C master with clock speeds of up to 50KHz.
OSIF
The Open Source InterFace (OSIF) is part of the OpenServo project, and I believe was designed by Barry Carter. Carter took the i2c-tiny-usb design, and adapted it to use an AVR with more pins, and upped the maximum I2C clock speed to 400KHz. Furthermore, the board has support for serial (I think UART), 6 GPIO lines and an ADC channel. Barry Carter sells the OSIF for £20 a board.
Carter also provides a kernel driver for the OSIF as well :-D
I bought an OSIF earlier today. I like the way that the OSIF uses work from two previous open hardware projects to create
| Older Posts >> |
Site by Robert Spanton. ©2008