fake's blog - Tag - embedded

GPIO to I2C on a Soekris net4801

fake — Thu, 20 Nov 2008 21:22:00 +0100

I recently started playing around with robots from arexx - a friend introduced me to the asuro, and - impressed by the steep learning curve - i got myself an RP6.

having toyed around with it, i remembered i had an old soekris net4801 lying around... which, unfortunately, does not have i2c ports pinned out - but it has 12 GPIO pins ... i quickly found i2c-gpio in the linux kernel, but that uses the arch-independent gpio layer called gpiolib. the soekris pc8736x gpio driver does not support this layer :(

i'm by far not a kernel developer, but i managed to insert a small wrapping layer that seems to work. it basically registers the pc8736x as generic gpio chip, additionally to the character device(s).

i repeat: i am not a kernel developer. this is a hack so ugly it will most likely not work for you. if you have a soekris net4801 (no, a net4501 will not work! it has lesser gpio pins! go count!) your chances are indefinitely higher it may work, but i don't guarantee anything. also, even the most basic cleanup code is missing - i am not removing the gpio chip on unload, i just dont' care for now.

included in the patch below is a i2c-gpio-generic module i found in the openwrt subversion by pure coincidence, it works very well. i just patched it so it hardcodes sda and scl to open drain, which is the default on the soekris.

to get i2c up and running on the gpio pins 0 and 1 (jp5 pins 3 and 4 on the connector!) with 0 being sda and 1 being scl, you have to

modprobe pc8736x_gpio
read dmesg and note the assigned lowest pin nr (244 for me)
modprobe i2c-generic-custom bus0=245,244,245 (the latter two being the number from above 1st, and 1 added to it 2nd. the first nr. is the i2c bus id. choose it to your liking.)
modprobe i2c-dev

that should enable you to run i2cdetect on the newly appeared bus.

a little warning: i wouldn't mess around with the character device while using this, especially not for the pins in use for i2c. you have been warned.

i also wrote a small test program that reads out the current light sensor value (left) of the rp6 running the IC2_Slave example program that it has been shipped with.

also, the *actual* pinout-to-minor-device-nr for the gpio character device might be of interest here:

Soekris	PC8736x	Minor Device #
GPIO 0	GPIO 20, 117	16
GPIO 1	GPIO 21, 118	17
GPIO 2	GPIO 22, 119	18
GPIO 3	GPIO 23, 120	19
GPIO 4	GPIO 24, 121	20
GPIO 5	GPIO 24, 122	21
GPIO 6	GPIO 26, 123	22
GPIO 7	GPIO 26, 124	23
GPIO 8	GPIO 4, 6	4
GPIO 9	GPIO 5, 7	5
GPIO 10	GPIO 13, 55	11
GPIO 11	GPIO 12, 54	10

kudos to the guy who found this out, it cost me 2 days to figure out the straightforward approach (GPIO 20 = minor 20?) was wrong.

here is the patch. handle with care. it's against linux-2.6.27.6. i used this .config to build the kernel.

NSLU2: Compiling a recent kernel

fake — Sat, 15 Dec 2007 16:19:00 +0100

I'm running the latest debian (etch, 4.0r1, which you need to install manually because of a problem with the firmware update as the slug-firmare.net page states) on my slug.

The latest kernel you seem to get with debian currently is 2.6.18, which is pretty outdated. So i went ahead and tried to assemble the stuff needed to build my own kernel, which was more work than i'd expected. The Linksys NSLU2 needs some proprietary firmware, but nevermind signing up at IBM, if you installed the image linked above, the firmware you need is in /lib/firmware/NPE-B. Just make sure the file stays there ;-)

The steps to build your own kernel are:

get your hands on a cross-toolchain (i use and enjoy crosstool, for version 0.43 i edited demo-arm-xscale.sh to use gcc 4.0.2 (ICE in 4.1.0) and glibc 2.3.6-tls, you'll probably need to put another patch for glibc into patches/glibc-2.3.6/, get it here). Make sure the tools are in your $PATH!
get the kernel sources (at the time of writing, 2.6.23.9 was the newest, which i used)

making sure you have subversion installed, issue the command:

svn co svn://svn.debian.org/svn/kernel/dists/trunk/linux-2.6/debian/patches/features/arm debian-arm-patches

extract the kernel sources, and apply the following patches

tar -xfj linux-2.6.23.9.tar.bz2
cd linux-2.6.23.9
patch -p1 < ../debian-arm-patches/ixp4xx-npe-driver-0.3.1.patch
patch -p1 < ../debian-arm-patches/ixp4xx-net-driver-improve-mac-handling.patch
patch -p1 < ../debian-arm-patches/nslu2-i2c-gpio-driver-support.patch
patch -p1 < ../debian-arm-patches/nslu2-mac_plat_info.patch
patch -p1 < ../debian-arm-patches/nslu2-setup-mac.patch

now it's time to configure your kernel, the debian defconfig is a little dated, so i upped my config. put it into your linux source dir and run:
```
mv nslu2-2.6.23.9.config .config
make ARCH=arm CROSS_COMPILE=arm-xscale-linux-gnu- oldconfig
```
if you want to edit the config (it's fairly basic), run the last line above with "menuconfig" at the end (you guessed it ;) big fat note: don't compile in the ixp4xx npe network driver, leave it as a module! the firmware is not part of the initramfs, so the network interface would never come up!

build your kernel:

make ARCH=arm CROSS_COMPILE=arm-xscale-linux-gnu- zImage modules
mkdir ../modules-2.6.23.9
make ARCH=arm CROSS_COMPILE=arm-xscale-linux-gnu- INSTALL_MOD_PATH=../modules-2.6.23.9 modules_install

That's basically it for compilation. Now all you need to do is copy the modules (maybe as a tar file) to the box so the modules end up where they belong; then copy arch/arm/boot/zImage to the box's /boot directory, naming it vmlinuz-2.6.23.9, for example. then run "mkinitramfs -o /boot/initrd.img-2.6.23.9 2.6.23.9". finally, you need to alter the symlinks 'vmlinuz' und 'initrd.img' in /boot to point to the newly created/copied files.

If you now run 'flash-kernel', it will flash the kernel and the initramfs into the nslu2's boot flash. don't worry - if anything goes wrong, just re-flash the image from the "manual install" link above.

reboot the slug and wait... good luck ;-) if it does not come up again, a good starting point is to simply unplug the external hard drive and check the logfiles.

have fun!

Linksys NSLU2 - the answer to your NAS requirements - and more!

fake — Tue, 11 Jul 2006 19:04:00 +0200

After the frustrating experiences i had with the Teac HD35-NAS (see my review), i looked around for an alternative solution. I didn't need to look around lot, until i found a product that perfectly fits me.

(it's actually smaller than a normal cd case, and about twice as thick)

The Linksys NSLU2 is a small device with very low power consumption that's ment to be used in connection with the USB drive enclosures you probably already own. But there's more - it runs Linux, and a very active community already evloved, bringing ports of common Linux Distributions like Debian to the "Slug" - as the device is called.

Read around the www.nslu2-linux.org page, and try to find someone *not* satisfied with the device - i wasn't able to. There are lots of users reporting what kind of stuff they do on the WhatPeopleAreReallyUsingTheirSlugsFor page. You also may want to de-underclock the device from 133 to 266 MHz, which is pretty easy.

I'll get a VGA USB Dongle and see if i can use this device as a very cheap thin client (it's only 79 EUR in 20% VAT austria, so it's probably even cheaper in .de). The possibilities are endless! I LOVE it!

Oh, and, yes, there is a 2-staged bootloader on there, so a failed firmware flash won't brick it, unlike the Teac HD35-NAS.

On that: i had correspondence with Dennis from www.aroundmyroom.com, who offers a customized firmware on his web-page, so he obviously has some inside knowledge. He enlightened me that the device does NOT have any rescue system for failed firmware flashes. Actually, i googled a lot more, and found out the device is based around a chip from RDC, the RDC2882, and has many rebranders: Hotway HD9-U2LA, Usbex LanDrive, FANTEC LD-H35NU2-2, FANTEC LD-M35NU2 -2, Macpower Pleiades USB/LAN, Mapower KC31N (which also looks *exactly* the same despite the logo. they have an extensive FAQ (german only, sorry!), also covering the hidden reset jumper and how to use it). I found all these via 2 very long forum threads here and here. I'll use the device as USB client for the Slug now ;)

bad timing and SIP frustration

fake — Mon, 07 Feb 2005 22:12:00 +0100

i wondered why openvpn on the soekris router kept telling me that the server certificate is 'not yet valid' - i thought the meaning was something like 'the certificate looks invalid now, but i haven't checked everything yet' (like the ssh -v authentication fall-through messages). eek. there was no 'date' utility on the box, but as the dsl link went down once again, i wanted to know when the cron-job would kick in, so i copied it over - it was the 3rd of January in 1980. Then it occured to me that openssl verify may be very aware of the fact that back then only very few certificates were valid ;) and of course the ca certificate was created somewhen in 2004, so a quick date -s (and hwclock --systohw) brought me back into the vpn (a setup where 6 routers of friends are connected, mostly for SIP and easy access to one's own boxen when at a friend), and with my free traffic/month kindly upgraded to 300GB/month, i went on installing SER on the vpn knot instantly.

unfortunately, no other participant of the VPN was availible, so i asked on the rock linux channel (#rocklinux on freenode.net) wether someone had a sip ua running by chance. daja even compiled kphone to help me out, but the frustration was big. as nice as sip is when used in non-NAT-areas, as much it sucks as soon as NAT comes into play. Okay, i admit, there was a time when i considered it perfectly normal to install a sip proxy on your router or at least do some port forwading and do the 'accpeted media ports'-dance - but then there was skype... the evil, evil skype that 'just works, nat or not'. kinda changed my view on that...

beside that, today was more the relaxed kind of day, not to say boring... believe it or not, i'm going to watch another episode of 'gilmore girls' now ... o_O