Monthly Archives: March 2011

Serial console on Samsung E60 reader

Thanks to some discounts last January in France, I got a Samsung E60 reader.

A community started around the french forum (e60 – hardware.fr) and the google code (e60-open).

There are many information there especially on the serial console. I own an USB to serial adapter that uses LVTTL 3.3V signals (based on FTDI FT2232C) so I choose to connect on R232 and R233. But RXD (R232) is already connected to the MAX232 chip that shift LVTTL levels to serial levels, and it seams that this chip is styronger than my FTDI… So I removed R232 to connect me FTDI there. Remains to know on which PAD ? Luckily the first one I tried was the one: the one on the battery side.

A picture on my nice soldering:
E60 RS232 LVTTL 3.3V

That was it. I then followed the testing a kernel procedure thus loading the kernel image from the project’s SVN. And it worked ! (except that I had to unload the secbulk module, so it’s either me or it’s useless).

Next time, compiling and testing a Linux kernel.

Triage X Bugs of the Week (TXBW18)

Better later than never, I restarted to triage last week, here is the report for it.

  • #526095 ping & close – KVM switch change makes mouse stop working.
  • #495139 upstream – cleanlinks: warning in “find” usage.
  • #550308 ping – x11-apps: xedit search dialog shows garbage.
  • #555647 ping – x11-xserver-utils: xrandr -o left leaves xdm, after I logout, unresponsive, with no login prompt.

In the mean time, Cyril has been triaging a lot of bugs see Debian XSF News #7.
But there are still 533 bugs to triage.

Mike Hommey recently wrote about graphs for the Debian Bug Tracking System. In particular there is now a per maintainer graph, so here it the X Strike Force bug graph ! (Note: the graph does not filter out some bugs as we do on UDD.

The X Strike Force (still) needs you !

You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

Benchmarking microSD

First, I didn’t ask manufacturers for free cards to run my tests, so this test is not comprehensive. In fact I’m only comparing two cards!
My brother and I bought some microSD SDHC 16G cards: one from SanDisk and one from Kingstone. We picked branded cards to ensure we had good performances.

Testing method

I was trying to define my test procedures, like copying several kind of file, when I found this blog: MicroSD class 6 Performance Benchmarks. He is using a tool from the GNOME desktop: palimpsest.
Well this tool doesn’t want to test cards if it detects a partition table on it. The above blog proposed to erase the card with the following command:

dd if=/dev/zero of=/dev/sdb

Erasing an SD card that way is probably not a so good idea. Especially when you know that the “erased” state of a flash is with all bits set to 1, so writing 0 everywhere is more like filling than erasing…
But I didn’t had this thoughts when I ran the test, so I went with:

sync; date; sudo time dd if=/dev/zero of=/dev/sdb; sync; date

Calls to date gives a first write time estimate, but in fact, dd gives some statistics so it was really not necessary.

Then the test itself:

LANG=C palimpsest

Beware when choosing and USB port for a SDHC adapter, if your kernel traces (dmesg) shows the following line you need to pick another port!

not running at top speed; connect to a high speed hub

OK, enough blah …

The results

Kingston microSD 16G SDHC Class 4

dd results: 15997075456 bytes (16 GB) copied in 6491.87 s (1h48) or 2.5 MB/s.

Reading performance (blue line):

  • Minimum read rate: 18.6 MB/s
  • Maximum read rate: 20.9 MB/s
  • Average read rate: 18.9 MB/s

Writing performance (red line):

  • Minimum write rate: 1.7 MB/s
  • Maximum write rate: 4.7 MB/s
  • Average write rate: 2.4 MB/s

Average access time: 2.2ms (green line)

kingstone microSD 16G performance graph

SanDisk microSD 16G SDHC Classe 4

dd results: 15931539456 bytes (16 GB) copied en 4934.48 s (1h22) or 3.2 MB/s

Reading performance (blue line):

  • Minimum read rate: 20.6 MB/s
  • Maximum read rate: 21.1 MB/s
  • Average read rate: 21.0 MB/s

Writing performance (red line):

  • Minimum write rate: 1.3 MB/s
  • Maximum write rate: 5.7 MB/s
  • Average write rate: 2.4 MB/s

Average access time: 1.6ms (green line)

SanDisk microSD 16G performance graph

Conclusion

Those two cards are similar with a light advantage for the SanDisk one.

First step in kernel development

I wanted to work on linux kernel from some time, but didn’t really know where to start. One day a wise man told me “a good way to learn is to do it! So get an USB device and write the driver for it.” I answered: “Well I didn’t thought of that, usually I’d use libusb for such cases.”

A USB device

Some days later, I didn’t find any nice device, but I thought, why not building it as well?
As I already told you, I’ve already hacked out an USB device: USBtinyISP. So I got back to the original code: usbtiny and I build myself a small device with 4 LED and 2 buttons:

My prototype's picture

I didn’t use and ATtiny, but an ATmega8 to keep more room for future improvements 😉 (The ATtiny2313 is already full with the USBtinyISP code).

And here is the schematic: (as picture, the gschem sources stay in git under the sch folder):

The schematic

Once the wiring done, some few lines of code based on the usbtiny sample, and that’s it: A firmware for the ATmega (in the root of the project).

Then I needed to test it, so back to the first idea, some code lines using libusb, available in the test, helped to improve the firmware 😉

Everything’s OK, let’s write a driver.

The Linux driver

Well I just followed some tutorials:

Finaly looking at the usbled.c file in Linux sources to get some more updates.

This build a module that adds the files leds and keys in the device folder that Linux creates in /sys/bus/usb/.

That’s it! I don’t know if you learned something, but I did learn a lot! 😉

All source code are available under GPL2 or GPL2+ on my gitweb: jvdg_usbgadget.git

As for the egocentric name, it’s just to avoid any name conflict. This has no mean to be integrated anywhere anyway. (The device uses an USB ID reserved to prototyping, so unusable for products…)