software

Posted on 08-09-2008 under general, linux

Debian recently froze Lenny. Which means that Debian 5.0 is coming out soon. September is an estimate I’m hearing.

But I’m already using the “testing” (or Lenny) version of Debian. This lets me use fairly new software (like Firefox 3.0), without having to wait a year and a half for it to get into the “stable” version. So how does Lenny being frozen help me? Well, when Lenny is released, I’ll be able to upgrade to Sid (which will become the new testing)!

I’ve been able to get my hands on most freshly baked software, once it passes stability testing. Like the mentioned Firefox 3 which I got only recently. Although still not hot out of the oven, it works for me. The one thing I haven’t been able to get is KDE 4. This has been out for some time now. And has recently been upgraded to 4.1. Don’t get me wrong Debian releases KDE 4 packages as fast as the coders can write them. The problem is that they’re released to “experimental” or more recently, “unstable”.

I could just wait till September for Lenny to be released, upgrade to Sid, and get KDE 4. Or I could upgrade to Sid right now. I’m not very eager about the latter though. My system is running pretty neatly and I don’t want it to become unstable just because I want a better desktop. On the other hand, KDE 4 looks to be worth it. But its not just the eye candy. KDE 4 runs faster as well. Decisions, decisions…

In other news, the embassy hasn’t returned my passport yet. Which means I can’t attend the Fulbright Gateway Orientation in New York. I was kind of expecting this, so I didn’t get myself too excited about it in the first place. Anyway, good luck to all those who are going to the Gateway.

This also means I have a problem in paying my accommodation fees. Northwood housing at University of Michigan doesn’t take credit cards. Dang.

Back to square one: waiting for my passport again. Deja vu ca. 2006. Maybe this will give me more time to look into this KDE issue…

UPDATE: 21st August, 2008 - Turns out sid is not going to become the next testing. Which means that I’ll have to wait for lenny to get released and the new testing to come out. More waiting :/

My visa has yet to show its face. And today was the recommended date for arrival at the university. I still have some time till classes start on September 2, but its looking very unlikely that I’ll make it. Deferral, here I come… yippee…

Posted on 07-23-2008 under howto, linux

I had been delaying this for a long time. Since I very rarely boot into Windows these days, it has been a real pain to access my phone’s memory card. I don’t have a card reader so I can’t do that either.

Earlier on I had looked into several ways I could do this, but nothing was clean and simple (like it should be). There was literally no way you could get away without having to put your hands right into the guts of the Linux OS and play around with devices and source code. And since, more often than not compiling source code fails because of some obscure dependency issues, I dropped the idea in favor of sanity.

Things have become a lot better since then. Thanks to Debian’s packaging system all you need to do is issue some commands and install something called openobex. I’m going to discuss what I did in order to get my Nokia 6630 to work with my Debian box using the USB cable that came with it. Start by updating your database and installing what we need.

# aptitude update# aptitude install obexftp obexfs

To check if your phone is being detected properly

# obexftp -u -l

Which should give you something like,

Found 2 USB OBEX interfaces
Interface 0:
          Manufacturer: Nokia
          Product: Nokia 6630
          Interface description: SYNCML-SYNC
Interface 1:
          Manufacturer: Nokia
          Product: Nokia 6630
          Interface description: PC Suite Services
Use '-u interface_number' to connect
Connecting...Segmentation fault

We need one piece of info from this list: the right interface. As you can see, Interface 1 describes itself as “PC Suite Service”, and this is what we will connect to.
Next we issue a command to list the parent directory on the phone.

# obexftp -u 1 -l
Connecting...done
Receiving "(null)"... <?xml version="1.0"?>
<!DOCTYPE folder-listing SYSTEM "obex-folder-listing.dtd"
  [ <!ATTLIST folder mem-type CDATA #IMPLIED>
  <!ATTLIST folder label CDATA #IMPLIED> ]>
<folder-listing version="1.0">
   <folder name="C:" user-perm="RW" mem-type="DEV" label="Phone memory"/>
   <folder name="E:" user-perm="RW" mem-type="MMC" label="NO NAME    "/>
</folder-listing>done
Disconnecting...done

We got our folder listing!! … But its all in XML. You can make out the folder names C: and E: in the last few lines. These represent the phone’s memory and the memory card respectively.

You could now use obexftp to copy files to and from your phone (read the man page for more details). An example:

# obexftp -u 1 -c E:/Music -p Take\ A\ Message.mp3
Connecting...done
Sending "E:"... Sending "Music"... done
Sending "Take A Message.mp3".../done
Disconnecting...done

This is all well and good but not really what we’re looking for. As much as I love the command line, and swear by its efficiency, I do like to use a GUI interface to manage my files. Never fear, obexfs is here!
ObexFS allows you to mount your phone so that it behaves like a normal directory. You can then access the directory in any file manager you want. It does this by using a little something called Filesystem in User Space.
First you will have to load the fuse module

 # modprobe fuse

Create a directory

 # mkdir /media/phone

Then

 # obexfs -u 1 /media/phone

Where 1 is our interface number from before. Getting a file listing should show you the directories C and E.

 # ls /media/phone

Oh glee! But wait, we’re not finished yet. If you’ve noticed we’ve been logged in as root the whole time. If you log out and try to access the mounted filesystem, you will not be able to do so as normal user! We have to fix this now.
First you’ll have to add yourself to the fuse group.

# usermod -a fuse zohair

Replace zohair with your username, of course.
Then add the following lines to /etc/fstab. (Note how the spaces in the command line disappear in the fstab listing)

obexfs#-u1      /media/phone    fuse    allow_other   0       0

The allow_other option is needed because by default only the user issuing the mount command can view a fuse filesystem. But we want everyone to see it.

# mount /media/phone

Done. Log out of root and access the files as normal user. If you can read but not write change the file permissions of /media/phone (or wherever you choose to mount your phone). You might have to unmount it in order to do so.

# umount /media/phone
# chmod 775 /media/phone

I’m not entirely sure that an unmount is necessay. The chmod option gives the owner (root) and the group (normal user) read, write and execute access while letting others only read and write.


REFERENCES:

EDITS:

Posted on 05-19-2008 under linux

The recent frequency of electric breakdowns, coupled with sitting in front of a dimmed laptop screen hoping against hope that the power would come back on before my battery died, produced an interesting result. Fortunately, my brain doesn’t need electricity to light bulbs in the air above my head.

With the blessings of KESC and Worldcall, I went through some web pages about ACPI, the linux power management framework. I found this website quite helpful. Really interesting stuff. (No seriously).

In particular, reading sections 6.3 and 6.4, I struck on a wonderful idea. What if I could log when KESC shuts down my electricity and when it brings it back up. Now what if that data were to be made available on the web!

No, its not that awesome. Still, it would be interesting to see the trends (or lack thereof), appearing through the statistics.

For those of you who don’t want to read my ravings about how I did it, here’s the link to the log. Let me know if you have any problems viewing it. Keep in mind, this is running off my laptop, with my not-so-reliable connection, so you might see some problems.

Now to the meat. There’s this daemon by the name of acpid which should be running on your linux system already. It’s included in most distributions, so if its not running you can probably install it very easily. This daemon has certain events that cause it to do certain things. For example, if you’ve got a laptop with some extra keys (brightness, hibernate etc.), its more than likely they’re functionality is controlled through the ACPI daemon. What we need to do is find the events corresponding to AC Power and Battery status. In my case these were ac_adapter and battery respectively. (If you haven’t read the sections in the article I mentioned earlier, I strongly recommend you do so before reading further. The path names could vary depending on your system, as they did in my case.)

What we need to know is that there needs to be a file in /etc/acpi/events/ that indicates which script to run when a particular even occurs. In addition, of course, there needs to be a script file for the acpi daemon to actually run when the event occurs. You can download my script files here.

You will probably have to change the paths in these scripts. The files powerlog.sh and battlog.sh should go into /etc/acpi, and the files ac_adapter and battery should go into /etc/acpi/events.

Once you’ve edited and copied to the proper directories, you need to restart the ACPI daemon. This can be done ( on a Debian system),

# /etc/init.d/acpid restart

And your scripts should start logging. Have fun!

For my part, I’ll keep my script running, and see what turns up.

Posted on 05-18-2008 under linux

Following on my previous two posts on No-IP, I finally figured out what was wrong with my system. In particular, even though the init scripts were installed, noip would not start at boot up. I had to manually run noip2 to start it up every time I rebooted.

The init scripts themselves were probably installed due to the debian package. I had earlier (naively) indicated that the init script would be installed by simply copying it to /etc/init.d/. This however is wrong and at the very least you would need to run update-rc.d to install it completely. A detailed description of init scripts under Debian can be read here.

I’m not sure if this was a problem with the debian package, but the script did not exist in /etc/rc2.d/. If you know anything about runlevels, you would know this is the runlevel in which debian enters after all initializations are complete to log the user in. I got wind of this when I did a find under the rc?.d directories

$ find /etc/rc*/ -name *noip*

which gave me

/etc/rc0.d/K20noip2
/etc/rc1.d/K20noip2
/etc/rc3.d/S20noip2
/etc/rc4.d/S20noip2
/etc/rc5.d/S20noip2
/etc/rc6.d/K20noip2

As you can see, rc2.d is missing. Sure enough adding a link in rc2.d fixed the problem.

Looking at the links in the other rc* directories, I found the name for the link I was about to create.

$ ls -l /etc/rc3.d/ | grep noip
lrwxrwxrwx 1 root root  15 2008-04-10 22:46 S20noip2 -> ../init.d/noip2

so,

# ln -s /etc/init.d/noip2 /etc/rc2.d/S20noip2

A quick reboot (ughh!) and a check

$ ps -A | grep noip
4108 ?        00:00:00 noip2

shows noip merrily buzzing away.

That was certainly a relief. I wasn’t looking forward to sludging through arcane scripting syntax, and obscure manuals.

…

Who am I kidding. I would’ve loved doing that :D

Posted on 04-16-2008 under electronics, howto, linux

After two days of banging my head against the wall, interspersed with issuing ineffectual commands, I’ve finally done it. (See shot below).

Xilinx Cable Connected and Running!

The cable drivers available with the Xilinx 9.1i software suite just won’t compile on my system. Apparently they use some proprietary functionality that does not support any kernel other than 2.4. And since I have 2.6 installed…

I had help from here, here and here.

Here’s a rundown of how I made it run on my system, which is a Debian 4.0 testing, with the following output for uname -a

Linux galileo 2.6.24-1-686 #1 SMP Thu Mar 27 17:45:04 UTC 2008 i686 GNU/Linux

I used bash throughout. If you use another shell, some commands may change.

1.

In order to avoid problems later, install libusb-dev and fxload.

 aptitude install libusb-dev fxload

2.

Make a directory somewhere to store the driver’s sources.

mkdir ~/tmp/xildriver
cd ~/tmp/xildriver

3.

Download the source tarball.

 wget "http://git.zerfleddert.de/cgi-bin/gitweb.cgi/
usb-driver?a=snapshot;h=HEAD;sf=tgz" -O usb-driver.tar.gz

(without the line breaks)

 tar zxvf usb-driver.tar.gz
 cd usb-driver

4.

Compile the driver.

 make

5.

copy the library to a lib directory.

 su
 cp *.so /usr/local/lib/
 exit

This step is totally optional. Just make sure you substitute the right path in the next step.

6.

make the linker aware of the new library

 export LD_PRELOAD=/usr/local/lib/libusb-driver.so

This step will need to be repeated every time you login. Or you can add it to your shell’s rc file. For bash this is /home/user/.bashrc.

All the previous steps are common to all tutorials and sources I’ve mentioned earlier. Its also given in the README file that comes with the source. After this though, its all from Verhaegen’s email.

7.

Make a new udev rule file
I absolutely do not understand this step, but I believe it has something to do with how the USB cable is detected.

 su
 vim /etc/udev/50-xilinx-usb-osdriver.rules    # a new file with arbitrary
#name ("50" is recommended)

Now paste this into the file and save it.

ACTION=="add", BUS=="usb", SYSFS{idVendor}=="03fd", MODE="666"

If you don’t know how to use vim, use nano instead ( or learn it). If you would rather use a graphical editor, then exit from root user and type

kdesu kwrite /etc/udev/50-xilinx-usb-osdriver.rules

Now restart udev.

 /etc/init.d/udev restart

8.

Get the bus and number of the USB cable.
Plug the board in and type

lsusb | grep Xilinx

Note the bus number and the device number. Here’s my output

 Bus 005 Device 016: ID 03fd:0008 Xilinx, Inc.

9.

Update firmware
If the ID in the above line is not 03fd:0008 in your case, do the following.

 su
 /sbin/fxload -v -t fx2 -I /home/zohair/installed/Xilinx91i/bin/
lin/xusbdfwu.hex -D /proc/bus/usb/005/016

Again without the linebreaks.
Replace your bus and device numbers from the above step into this command.

10.

Start impact (as normal user of course)

 ~/installed/Xilinx91i/bin/lin/impact


Impact should detect your cable automatically. If it does not go to Output->Cable Setup: and choose Xilinx USB cable.


If it still does not work, there are some more instructions in Verhaegen’s email (steps 13 onwards).


Credits


Credits go to Michael Gernoth who took the time out to make these drivers. And also to Paul Verhaegen’s excellent email and  Luzerne GANHIR . Thanks guys.

										

			



						

				« Previous entries