• Home
  • Help
  • Search
  • Login
  • Register
  Show Posts
Pages: [1] 2 3
1  Hardware and U-Boot firmware / Hardware / Re: Replaced power supply, booted, now brick with no lights...? on: July 31, 2010, 08:47:59 AM
Could it be that the battery made up the difference between the needs of the plug and the underpowered 5v source for about 10 minutes?

Total conjecture here, but it could be that the rapid discharge of the battery caused it to deteriorate.

2  Linux Stuff / General Linux questions / Re: SSH, su, adduser do not work on debian on: March 01, 2010, 12:00:03 AM
I have the same problem, just noticed it recently. I think it was working fine for a long time, but it stopped after installing X and doing a bunch of install/remove cycles on various things.

I burned a couple hours trying to figure it out, and didn't get anywhere. PAM doesnt seem to be logging anything crazy (and i did debug on all PAM modules that support it)

sudo just says 'killed'

I'll try the ""aptitude dist-upgrade"" method and see what happens.

3  General Category / Application ideas and development Q/A / Re: DisplayLink integration? on: February 21, 2010, 05:38:37 PM
Hi folks,

I got an 'imo pivot touch' monitor working (eventually) on my sheevaplug.

Here's my steps:

1) kernel module: This piece needed compiling. the EDID on mine was also 0x0, which messed with xwindows. There may be an X or hald setting to ignore that, but I was already using a custom kernel, so the driver wasn't a big deal. If someone finds a workaround for this (HALD config?) then you can just use the stock kernel module.

I used the 'udlfb' module, and pretty much did exactly what an earlier post suggested:

dmesg output:
DisplayLink device attached
ret control msg 0: 4 1500f0
INIT VIDEO 0 800 480
ret control msg 1 (STD_CHANNEL): 16
ret bulk 2: 156 156
ret bulk 3: 0
found valid mode...0
screen base allocated !!!
colormap allocated

2) X config. Several things going on here:
Video: I had the same problem as a previous poster, that the fonts were way too big. the DPI was off. To correct it, i looked up the size of the monitor's viewable area: 155mm x 93mm. I put those values in and it worked.

I don't remember if i had to install the displaylink driver, now that i think of it. I may have compiled it. At any rate that's what i used

if i did, this was the one i used:
wget http://projects.unbit.it/downloads/udlfb-0.2.3_and_xf86-video-displaylink-0.3.tar.gz
tar xvf udlfb-0.2.3_and_xf86-video-displaylink-0.3.tar.gz
cd xf86-video-displaylink/
make install
If it complains about missing X packages, install xorg-dev (you can uninstall it after)

full xorg config at the end of the post

I installed the 'evtouch' driver for the touchscreen ( apt-get install xserver-xorg-input-evtouch )
But it didn't work, and kept saying 'couldn't grab device'. Turns out the synaptics driver had it and didn't let go. Rather than fight it, i just removed that driver ( apt-get remove xserver-xorg-input-synaptics )

The calibration wouldn't work at all, no matter what i tried. Kept complaining about a missing font. ( '*freemono*' i think it was ). However, the touchscreen seemed to be working ok, except that the X axis was mirrored, eg touching the left-side middle would move the pointer to the right-side middle.

I tried all sorts of X configurations, but nothing worked, eventually i found that the HALD cfg file was overriding everything. The driver claims to support a  a 'SwapX' command, but i never did get that to work. I ended up just swapping x-min and x-max. Here is my final configuration:

swapped xmin and xmax
file contents:
<?xml version="1.0" encoding="UTF-8"?> <!-- -*- SGML -*- -->
<deviceinfo version="0.2">
    <match key="info.product" contains="eGalax">
      <match key="info.capabilities" contains="input">
        <merge key="input.x11_driver" type="string">evtouch</merge>
        <merge key="input.x11_options.minx" type="string">3945</merge>
        <merge key="input.x11_options.miny" type="string">197</merge>
        <merge key="input.x11_options.maxx" type="string">130</merge>
        <merge key="input.x11_options.maxy" type="string">3894</merge>
        <merge key="input.x11_options.taptimer" type="string">30</merge>
        <merge key="input.x11_options.longtouchtimer" type="string">750</merge>
        <merge key="input.x11_options.longtouched_action" type="string">click</merge>
        <merge key="input.x11_options.longtouched_button" type="string">3</merge>
        <merge key="input.x11_options.oneandhalftap_button" type="string">2</merge>
        <merge key="input.x11_options.movelimit" type="string">10</merge>
        <merge key="input.x11_options.touched_drag" type="string">1</merge>
        <merge key="input.x11_options.maybetapped_action" type="string">click</merge>
        <merge key="input.x11_options.maybetapped_button" type="string">1</merge>
be sure to restart hald after making the change

My full X config:
Section "Files"
        ModulePath      "/usr/lib/xorg/modules"
        ModulePath      "/usr/local/lib/xorg/modules"

Section "ServerLayout"
        Identifier      "Server Layout"
        Screen  0       "DisplayLinkScreen"

Section "Device"
        Identifier      "DisplayLinkDevice"
        driver          "displaylink"
        Option  "fbdev" "/dev/fb0"

Section "InputDevice"
        Identifier      "touchscreen"
        Driver  "evtouch"
        ## not sure these even do anything
        Option  "ReportingMode" "Raw"
        Option  "Emulate3Buttons"
        Option  "Emulate3Timeout"       "50"
        Option  "SendCoreEvents"  "On"

Section "Monitor"
        Identifier      "DisplayLinkMonitor"
        DisplaySize  155 93

Section "Screen"
        Identifier      "DisplayLinkScreen"
Device          "DisplayLinkDevice"
        Monitor         "DisplayLinkMonitor"
        SubSection "Display"
                Depth   24
Modes   "800x480"

cheers, hope this helps someone
4  Hardware and U-Boot firmware / Hardware / Re: i2c and/or GPIO? on: June 15, 2009, 08:35:40 AM
In order to do i2c over GPIO's (data lines of SDIO interface on Sheevaplug,
1. you need to first modify kernel configuration to disable SDIO driver,
6. then test the interface... good luck :-)

The exercise may not be as simple as I have explained above...

yep, that's pretty much how it went Smiley

I posted pics and such here:
http://openplug.org/plugforum/index.php?topic=104 (scroll down)

5  Hardware and U-Boot firmware / Hardware / Re: i2c and/or GPIO? on: June 14, 2009, 05:03:38 PM
I've updated a few other threads.

My solution to this and other problems was to just get at the pins via GPIO, and then bit-bang the desired protocols.

In order to make the gpio pins available, I believe you do need to edit some of the kernel code and note that the pins are available.

Also, you'll need some sort of custom-module to tell the kernel which gpio pins are to be used for what purpose.

I was able to bit-bang the dallas 1-wire bus pretty easily, and i'm assuming i2c should work fine also. Haven't needed to yet.

6  General Category / Success stories / Re: USB GPIO on: May 02, 2009, 12:41:45 AM
I'm looking to see if anyone has found any cheap USB accessible GPIO that might work with this device.  I came across a few options most of them very expensive for what you get.


Thought i'd update the thread; I picked up one of these modules, and so far it works well.

I /also/ got the GPIO working on the board itself, but my application would benefit from not having to cobble together an SDIO->wire interface.. something more permanent is better.

On the usb stick, there are 12 usable GPIO pins, broken into a set of 8 and a set of 4. It does not appear that you can use all 12 at once though. The first 8 are in lieu of the normal serial function, and the second 4 you can use even if you're using the rest of the chip for serial IO. To get at the second 4 you have to change the eeprom, which doesn't seem to be documented under linux. They provide a windows flasher, but i don't have a windows box to test it on.

The programming is (as the marketing indicates) easy, using libftdi. There are bit-bang examples in the libftdi distribution.

I still need to see what sort of response time i can get out of it, to see if it will work as a dallas 1-wire master. The commands are just sent over USB, so it will depend on the speed of the bus, and the baudrate that the FTDI chip is running at (when you write GPIO bits, the new state takes effect when the baud clock ticks to the next signal)

The datasheet also mentions that when in bitbang mode, the baudrate is multiplied by 4.

There is both a standard USB port and a "mini" USB port on the plug.  Not sure if they have the same functionality.  I just got my plug yesterday and haven't played with it yet.
The mini-usb is for console/jtag access, not for devices.

7  Hardware and U-Boot firmware / U-Boot stuff / Re: Can't get NFS boot to work on: May 02, 2009, 12:02:32 AM
Did you 'set mainlineLinux yes' or whatever the syntax is? You have to set it correctly.. If using the kernel packaged with sheevaplug, then mainlineLinux=no, if you compiled your own, mainlineLinux=yes.

It's documented somewhere, probably in the kernel config section.

Also you'll probably have to set the arcnum to 2097 or whatever it is.


8  Linux Stuff / General Linux questions / Re: apt-get not working on: May 01, 2009, 10:52:28 PM
'apt-get update' fixed it for me

9  Hardware and U-Boot firmware / Hardware / Re: SheevaPlug v2 - Hardware Requests on: May 01, 2009, 12:08:27 AM
I'd like to see as many of the hardware features exposed as accessible pins/headers as possible.

The current model, with 2 gig-e ports, one or two more USB ports, and easy access to i2c/gpio pins would be perfect.

I realize that the GPIO pins are sort of available, but I had to work hard to get at them. (finally managed, see: http://openplug.org/plugforum/index.php?topic=104.msg647#msg647)

Perhaps expose the sata pins as well, but usb2.0 gets you most of the way there.

I can say for certain that USB is fine for HD video (max bitrate ~20mbit/sec = 2.x mbyte/sec). I use a USB tuner for OTA HDTV and it works great. Wouldn't complain about 3.0 support tho Wink

10  Linux Stuff / Kernel / Re: anyone compile a custom kernel yet? on: April 30, 2009, 03:26:52 PM
Have you tried booting your kernel from tftp/network or otherwise, just to make sure it's supported?

I haven't yet flashed a kernel to the uboot space yet.

11  Linux Stuff / Kernel / Re: anyone compile a custom kernel yet? on: April 29, 2009, 11:55:13 PM
what command did you use for reflashing?

i had problems when i used the -p flag to nandwrite (i think it's that command anyways, the -p flag is definitely a problem)

12  Hardware and U-Boot firmware / Hardware / Re: Probing gpio pins from userspace using /dev/mem on: April 25, 2009, 11:00:53 PM
Finally figured it all out.. it was a timing issue, and my parts were "parasite power only", which means i needed to do some kernel hacking to add support for that feature..

patches and such are posted over here:


13  Hardware and U-Boot firmware / Hardware / generic GPIO support: success! dallas 1-wire working with parasite power on: April 25, 2009, 10:59:42 PM
After quite a few days of hacking at the kernel and trying to debug my 1-wire bus, i am pleased to report success!

I have a working 1-wire bus using the GPIO pins on the plug (disabling SDIO gives you GPIO)

see this thread for lots of pictures and details on how i wired it all up. http://openplug.org/plugforum/index.php?topic=104.msg647#msg647

Now that it's all working, i can read my 2 temp sensors on the shared bus:
root@charger:~# cat /sys/bus/w1/devices/28-000001c76810/w1_slave
a7 01 4b 46 7f ff 09 10 e0 : crc=e0 YES
a7 01 4b 46 7f ff 09 10 e0 t=26437
root@charger:~# cat /sys/bus/w1/devices/28-000001c77bdc/w1_slave
a3 01 4b 46 7f ff 0d 10 ce : crc=ce YES
a3 01 4b 46 7f ff 0d 10 ce t=26187

as you can see, it's ~26 C in here Smiley

Here's all the details:
I decided to use the 2.6.30-rc2 kernel, as it has support for the GPIO kirkwood stuff built-in, and i needed to do less hacking.

I also got a kernel driver from the openwrt package (who got it from somewhere else i think) which allows you to specify which GPIO pin to use for 1-wire at module load-time (or kernel config option, if compiled in)

get it here: https://dev.openwrt.org/browser/branches/8.09/package/w1-gpio-custom/src/w1-gpio-custom.c

I had to apply the following patch to it to get it to load.
--- w1-gpio-custom.c 2008-04-29 11:31:43.000000000 -0700
+++ tmk-w1-gpio-custom.c 2009-04-25 22:09:46.112712798 -07
@@ -119,7 +119,7 @@
  if (err)
  goto err;
- err = platform_device_register(pdev);
+ err = platform_device_add(pdev);
  if (err)
  goto err;

Note: it segfaults if you unload/reload and use the same bus#. I haven't tracked that down yet, but i think it's calling the wrong function as part of the _cleanup process.

4 bus #s are supported by default, so you basically get 4 loads/unloads before you need to reboot. eg

This works:
## try 1, pin 13
modprobe w1-gpio-custom bus0=0,13,0
rmmod w1-gpio-custom
## try 2, still pin 13
modprobe w1-gpio-custom bus1=1,13,0

Also, in order for this module to work, you have to add the GPIO pins to the available pool. Not sure if this breaks SDIO or not.
--- sheevaplug-setup.c 2009-04-14 13:51:48.000000000 -0700
+++ tmk-sheevaplug-setup.c 2009-04-25 22:43:55.187247857 -0700
@@ -97,6 +97,12 @@
 static unsigned int sheevaplug_mpp_config[] __initdata = {
+ MPP12_GPO, /* shared with sdio - output only*/
+ MPP13_GPIO, /* shared with sdio */
+ MPP14_GPIO, /* shared with sdio */
+ MPP15_GPIO, /* shared with sdio */
+ MPP16_GPIO, /* shared with sdio */
+ MPP17_GPIO, /* shared with sdio */
  MPP29_GPIO, /* USB Power Enable */
  MPP49_GPIO, /* LED */

That's it for the base stuff. Not too bad. However, i had to make some tweaks to the w1 drivers in the kernel to support the ds18B20 temperature probe (and anything else that needs 'strong pullup' support). The probe needs 'parasite power', which wasn't supported in the default kernel. Again, the following aren't needed unless you have things that need a 'strong pullup' on the 1-wire bus.

a bunch of files need patching for this:

--- w1_int.c 2009-04-14 13:51:48.000000000 -0700
+++ tmk-w1_int.c 2009-04-25 21:44:58.503236242 -0700
@@ -118,12 +118,14 @@
  * pullup.  w1_io.c would need to support calling set_pullup before
  * the last write_bit operation of a w1_write_8 which it currently
  * doesn't.
- */
+ *
+ * added it, commenting this bit out -tmk
  if (!master->write_byte && !master->touch_bit && master->set_pullup) {
  printk(KERN_ERR "w1_add_master_device: set_pullup requires "
  "write_byte or touch_bit, disabling\n");
  master->set_pullup = NULL;
+ */
  /* Lock until the device is added (or not) to w1_masters. */

drivers/w1/w1_io.c: this one's a hack to fix the timing, and will break the one other driver that uses the set_pullup stuff. It should really go somewhere else, but i didn't want to deal with the kernel infrastructure of adding a new function type. This is what the long comment on the above patch is trying to point out.
--- w1_io.c 2009-04-14 13:51:48.000000000 -0700
+++ tmk-w1_io.c 2009-04-25 22:33:59.919237033 -0700
@@ -142,9 +142,9 @@
  for (i = 0; i < 8; ++i) {
+ w1_touch_bit(dev, (byte >> i) & 0x1);
  if (i == 7)
- w1_touch_bit(dev, (byte >> i) & 0x1);

drivers/w1/masters/w1-gpio.c: Had to add support for the strong pullup function
--- w1-gpio.c 2009-04-14 13:51:48.000000000 -0700
+++ tmk-w1-gpio.c 2009-04-25 22:38:00.571236272 -0700
@@ -12,12 +12,34 @@
 #include <linux/module.h>
 #include <linux/platform_device.h>
 #include <linux/w1-gpio.h>
+#include <linux/delay.h>
 #include "../w1.h"
 #include "../w1_int.h"
 #include <asm/gpio.h>
+static int w1_gpio_set_pullup(struct platform_device *data, int delay)
+ struct w1_gpio_platform_data *pdata = data;
+        if (delay == 0)
+ {
+ /* sleep */
+ msleep(last_duration);
+ /* bring pin back low */
+ gpio_direction_input(pdata->pin);
+ } else {
+ /* bring pin high */
+ gpio_direction_output(pdata->pin, 1);
+ }
+ last_duration = delay;
+ return 0;
 static void w1_gpio_write_bit_dir(void *data, u8 bit)
  struct w1_gpio_platform_data *pdata = data;
@@ -67,7 +89,10 @@
  master->write_bit = w1_gpio_write_bit_val;
  } else {
- master->write_bit = w1_gpio_write_bit_dir;
+ master->write_bit  = w1_gpio_write_bit_dir;
+ /* Can't vouch for strong pullup for open-drain setups */
+ master->set_pullup = w1_gpio_set_pullup;
  err = w1_add_master_device(master);

include/linux/w1-gpio.h:  added the last_duration bit. Could probably be handled cleaner by moving the set_pullup call to the post_write part, and not needing to store the timeout at all.
--- w1-gpio.h 2009-04-14 13:51:48.000000000 -0700
+++ tmk-w1-gpio.h 2009-04-25 21:45:48.955954736 -0700
@@ -20,4 +21,7 @@
  unsigned int is_open_drain:1;
+/* stores the last duration requested for a pullup wait */
+int last_duration = 0;
 #endif /* _LINUX_W1_GPIO_H */

i *think* that's what it took for me. I'll help if i can. If you try it, let me know how it goes!

14  Hardware and U-Boot firmware / Hardware / Re: Probing gpio pins from userspace using /dev/mem on: April 20, 2009, 08:13:51 AM
Here are some pictures of my on-the-cheap interface into the built-in GPIO pins:

I'm pleased to report that using the w1-gpio-custom driver from openwrt, i was able to get dallas 1-wire working using the GPIO stuff in the 2.6.30-rc2 kernel

I had a ton of issues along the way:
 * openwrt driver had some bugs which prevented module load/unload.
 * kernel didn't define the pins as gpio, had to edit the sheevaplug-setup.c file and add them
 * kernel bug described here http://lkml.indiana.edu/hypermail/linux/kernel/0904.2/00170.html bit me, had to correct it

I have a dallas temp sensor (DS 18b20), which reports and is discovered, but isn't giving valid readings (seems stuck in init mode.)

out of time for today, but heres the general steps to get it working:

modprobe w1_therm
modprobe wire
#i used pin 13:
modprobe w1-gpio-custom bus0=0,13,0
modprobe w1_gpio

cd /sys/bus/w1/devices
cd 28-000001c77bdc
cat w1_slave

here's sample output. According to the data sheet, 85 celsius is the default init value

root@charger:/sys/bus/w1/devices/28-000001c77bdc# cat w1_slave
50 05 4b 46 7f ff 0c 10 1c : crc=1c YES
50 05 4b 46 7f ff 0c 10 1c t=85000
15  Hardware and U-Boot firmware / Hardware / Re: Probing gpio pins from userspace using /dev/mem on: April 19, 2009, 11:59:15 PM
Worth nothing that the above technique does not work on mainline 2.6.30-rc2.

I think the closer control of the GPIO stuff in the kernel breaks it. Each time i tried to modify the control register (to configure the pins for GPIO), it locked up on me.

also in 2.6.30-rc2, the values in the control register appear to be invalid, based on the datasheet. 18,19 are both set to '3' which is undocumented, and 16,17 are set to '2', which doesn't make sense.

Pages: [1] 2 3