[OpenWrt-Devel] Anyone using a 2.6.22 kernel on ixp4xx ?
I want to use the ad7418 driver which is new in 2.6.22. I'm wondering if it would be easier to a) use that kernel or b) make a patch to back-port the driver to the existing 2.6.20 kernel ? Anyone have any thoughts ? Generally I'd expect some of the patches would not apply to the newer kernel, but I haven't tried them yet. Thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Anyone using a 2.6.22 kernel on ixp4xx ?
Imre Kaloz wrote: > I had a .22-rc patchset, and have a .22 port somewhere. We didn't > migrate due to the problems with the IDE controller with .22 on the FSG3. > I can clean it up and put it online today or tomorrow if you want to > give it a try. That'd be useful if you could, thanks. I'd begun to work through the patches, figuring out which had already been applied to the .22 tree (quite a few, it seems), but had only got through the first four or five by the time I fell asleep last night :( ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] For review : AD7418 patch
I back-ported the AD7418 temp/voltage sensor driver from 2.6.22
to OpenWrt 7.07. Complete patch attached, and also copies of
the various post-patched files for ease of reviewing.
I didn't totally understand what I was doing with the build file
changes in openwrt so please excuse any blunders. I copied
existing macros. Note that ad7418 depends on hwmon, however
I do not explicitly declare that dependency in openwrt because
there is no package for hwmon (there is a package for hwmon-vid,
but that driver doesn't pertain to ixp4xx hardware and the kernel
build doesn't make it even if you ask it to in that case so...
I guess I'm depending on the kernel config enabling hwmon.
It appears that it does so by default and that hwmon is always built-in).
I used the newest code from 2.6.22, and not one of the older patches
that I found around the 'net.
This driver is useful to anyone with Gateworks Avila hardware,
as it allows temperature and board power supply input voltage
monitoring.
If you have 7.07 installed on a Gateworks Avila or other
board with this device, you should be able to apply my patches
to a checked-out 7.07 tree, run make menuconfig and under
kernel modules->other modules you should enable kmod-hwmon-ad7418
Then build which should produce this package:
bin/packages/kmod-hwmon-ad7418_2.6.21.6-ixp4xx-1_armeb.ipk
Install that package on the board then you should see this:
[EMAIL PROTECTED]:~# ipkg install kmod-hwmon-ad7418_2.6.21.6-ixp4xx-1_armeb.ipk
Installing kmod-hwmon-ad7418 (2.6.21.6-ixp4xx-1) to root...
Configuring kmod-hwmon-ad7418
Done.
[EMAIL PROTECTED]:~# lsmod
Module Size Used byTainted: P
ad7418 3672 0
...
[EMAIL PROTECTED]:~# dmesg
...
ad7418 0-0028: ad7418 chip found
ad7418 0-0028: configuring for mode 1
And now you can read temp and voltage like this :
[EMAIL PROTECTED]:~# cat /sys/bus/i2c/devices/0-0028/temp1_input
45500
[EMAIL PROTECTED]:~# cat /sys/bus/i2c/devices/0-0028/in1_input
669
45500 above means 45.5 degrees C (the chip has 0.25C resolution
but the driver quantizes on 0.5C due to the use of a shared macro
from lm_sensors).
669 above means (669/1024) * 2.5v read at the input to the chip.
The Avila has a divider between the board input and the chip with
a 23:1 ratio (actually on my board I measure it as 27:1).
Any comments/complaints/feedback welcome.
If this is acceptable I'd also like to figure out how to get it
into svn.
Thanks.
Index: target/linux/ixp4xx-2.6/config/default
===
--- target/linux/ixp4xx-2.6/config/default (revision 8834)
+++ target/linux/ixp4xx-2.6/config/default (working copy)
@@ -407,6 +407,7 @@
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
+CONFIG_SENSORS_AD7418=m
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATXP1 is not set
Index: target/linux/ixp4xx-2.6/patches/910-ad7418.patch
===
--- target/linux/ixp4xx-2.6/patches/910-ad7418.patch(revision 0)
+++ target/linux/ixp4xx-2.6/patches/910-ad7418.patch(revision 0)
@@ -0,0 +1,408 @@
+diff -Naur linux-2.6.21.6/drivers/hwmon/ad7418.c
linux-2.6.21.6_patched/drivers/hwmon/ad7418.c
+--- linux-2.6.21.6/drivers/hwmon/ad7418.c 1969-12-31 17:00:00.0
-0700
linux-2.6.21.6_patched/drivers/hwmon/ad7418.c 2007-09-17
22:03:43.0 -0600
+@@ -0,0 +1,373 @@
++/*
++ * An hwmon driver for the Analog Devices AD7416/17/18
++ * Copyright (C) 2006-07 Tower Technologies
++ *
++ * Author: Alessandro Zummo <[EMAIL PROTECTED]>
++ *
++ * Based on lm75.c
++ * Copyright (C) 1998-99 Frodo Looijaard <[EMAIL PROTECTED]>
++ *
++ * This program is free software; you can redistribute it and/or modify
++ * it under the terms of the GNU General Public License,
++ * as published by the Free Software Foundation - version 2.
++ */
++
++#include
++#include
++#include
++#include
++#include
++#include
++#include
++#include
++
++#include "lm75.h"
++
++#define DRV_VERSION "0.3"
++
++/* Addresses to scan */
++static unsigned short normal_i2c[] = { 0x28, I2C_CLIENT_END };
++/* Insmod parameters */
++I2C_CLIENT_INSMOD_3(ad7416, ad7417, ad7418);
++
++/* AD7418 registers */
++#define AD7418_REG_TEMP_IN0x00
++#define AD7418_REG_CONF 0x01
++#define AD7418_REG_TEMP_HYST 0x02
++#define AD7418_REG_TEMP_OS0x03
++#define AD7418_REG_ADC0x04
++#define AD7418_REG_CONF2 0x05
++
++#define AD7418_REG_ADC_CH(x) ((x) << 5)
++#define AD7418_CH_TEMPAD7418_REG_ADC_CH(0)
++
++static const u8 AD7418_REG_TEMP[] = { AD7418_REG_TEMP_IN,
++ AD7418_REG_TEMP_HYST,
++ AD7418_REG_TEMP_OS };
++
++struct ad7418_data {
++ struct i2c_client client;
++ struct class_device *class_dev;
++ st
[OpenWrt-Devel] Any ideas on how to work around madwifi bug #705 ?
Madwifi has a major problem with 802.11a sensitivity that makes it pretty much useless for long links. (the entire sorry tale can be seen in this bug : http://madwifi.org/ticket/705) I'm wondering if there is any prospect of making a 'fixed' madwifi that is compatible with OpenWrt. This appears to be problematic because the fix made to openwrt is at present only in their 0.9.4 release, and not in the trunk releases used in OpenWrt. Furthermore, it isn't a simple case of patching the fix into the trunk code because it depends on HAL behavior that is not present in the HAL version used by the trunk madwifi code. This implies that it would be necessary to build a 0.9.4 version of madwifi for OpenWrt. This in turn looks tricky because many of the patches OpenWrt applies to madwifi do not apply to the 0.9.4 code. Has anyone else done battle with this ? Any thoughts ? Right now my best option is to switch to Mikrotik :( Thanks for your time. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Any ideas on how to work around madwifi bug #705 ?
Hmm...looks like someone has already done the work to integrate madwifi 0.9.4: https://dev.openwrt.org/ticket/3270 David Boreham wrote: > Madwifi has a major problem with 802.11a sensitivity that makes it > pretty much useless for long links. > (the entire sorry tale can be seen in this bug : > http://madwifi.org/ticket/705) > > I'm wondering if there is any prospect of making a 'fixed' madwifi that > is compatible with OpenWrt. This appears to be problematic because > the fix made to openwrt is at present only in their 0.9.4 release, and not > in the trunk releases used in OpenWrt. Furthermore, it isn't a simple case > of patching the fix into the trunk code because it depends on HAL behavior > that is not present in the HAL version used by the trunk madwifi code. > This implies that it would be necessary to build a 0.9.4 version of madwifi > for OpenWrt. This in turn looks tricky because many of the patches > OpenWrt applies to madwifi do not apply to the 0.9.4 code. > > Has anyone else done battle with this ? Any thoughts ? > Right now my best option is to switch to Mikrotik :( > > Thanks for your time. > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Any ideas on how to work around madwifi bug #705 ?
Felix Fietkau wrote: I believe that http://madwifi.org/changeset/3375 is what you're looking for. Unfortunately no. That changeset you will see says : /* NB: INTMIT was not implemented so that it could be enabled/disabled, * and actually in 0.9.30.13 HAL it really can't even be disabled because * it will start adjusting registers even when we turn off the capability * in the HAL. So this fix won't work with the madwifi used by openwrt because it depends on the 0.9.30 HAL, which is broken. However, using this patch, it seems I should be able to switch to the (working) 0.9.4 madwifi : https://dev.openwrt.org/ticket/3270 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Any ideas on how to work around madwifi bug #705 ?
Roberto Riggio wrote: > I was looking for this too. I will give it a try tomorrow on our mesh testbed. > That'd be very interesting thanks. I've got as far as launching a build of 7_07 (which is what we are running in the field) that includes the 0.9.4 madwifi integration from https://dev.openwrt.org/ticket/3270). I'm hoping that there are no broken dependencies vs. the more recent trunk version of OpenWrt that the original author made the patches against (they apply, I'm not sure yet if the result both builds and runs). I also have to make sure that this madwifi code works on iXP425 -- there have been cases in the past where it didn't. Reviewing the code, it _looks_ like all the bugs that I'm aware of are fixed. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Any ideas on how to work around madwifi bug #705 ?
David Boreham wrote: Roberto Riggio wrote: I was looking for this too. I will give it a try tomorrow on our mesh testbed. That'd be very interesting thanks. I've got as far as launching a build of 7_07 (which is what we are running in the field) that includes the 0.9.4 madwifi integration from https://dev.openwrt.org/ticket/3270). I'm hoping that there Well bad news. I was able to build the 0.9.4 madwifi driver in a 7_07 tree. However once I installed the package, my system threw a kernel panic at driver initialization. I have a spare Avila board coming in a few days which will allow me to play around in safety with this. It may be that with a more recent kernel it'll work. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Any ideas on how to work around madwifi bug #705 ?
Felix Fietkau wrote: I think you misunderstood the comment. This patch was added precisely because the HAL does not provide the API to disable ANI. Also it was added to trunk, which has that specific HAL version in question. Just give it a try :) Hmm...I will do thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Any ideas on how to work around madwifi bug #705 ?
David Boreham wrote: Felix Fietkau wrote: I think you misunderstood the comment. This patch was added precisely because the HAL does not provide the API to disable ANI. Also it was added to trunk, which has that specific HAL version in question. Just give it a try :) Hmm...I will do thanks. It turns out that trying this code is quite a bit of work (Openwrt trunk is using r3314 and the madwifi patches don't apply to r3505 or later). Last time I went through the patch set fixing it up it took a day or so. Any chance you've already made a compatible patch set ? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Any ideas on how to work around madwifi bug #705 ?
David Boreham wrote: David Boreham wrote: Felix Fietkau wrote: I think you misunderstood the comment. This patch was added precisely because the HAL does not provide the API to disable ANI. Also it was added to trunk, which has that specific HAL version in question. Just give it a try :) Hmm...I will do thanks. It turns out that trying this code is quite a bit of work (Openwrt trunk is using r3314 and the madwifi patches don't apply to r3505 or later). Last time I went through the patch set fixing it up it took a day or so. Any chance you've already made a compatible patch set ? btw, the fix I'm trying to use is in the trunk, rather than the DFS branch version you pointed me at earlier. This one : http://madwifi.org/changeset/3505 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] I'm integrating a more recent madwifi : any pointers?
I want to have trunk OpenWrt pick up this fix in madwifi : http://madwifi.org/changeset/3505 I've been through this exercise once before (figuring out which of the patches applied to madwifi are now included in the upstream, which are no longer needed, etc). However, I'm sure that others here know a lot more about this than I do. So I'm looking for any hints, advice, etc. For example, should I just pick whatever happens to be on the madwifi trunk today ? Or is there a golden version between 3505 and the current revision that would be better ? Is the current OpenWrt trunk known to be unstable ? Would I be better using an older revision ? Is the current code known to be stable on iXP425 ? Any help most welcome. Thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Any ideas on how to work around madwifi bug #705 ?
Felix Fietkau wrote: btw, the fix I'm trying to use is in the trunk, rather than the DFS branch version you pointed me at earlier. This one : http://madwifi.org/changeset/3505 Well, what I actually meant was: try to backport this one to the OpenWrt version of MadWiFi - that shouldn't be too hard to do Ha, I thought you were saying that you'd tried it out already :) So...see my other post earlier today: I'm going to integrate the newer version of madwifi trunk, which is the fix (actually a somewhat better fix, but fixing the same problem) since r3505. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Berekely DB porting
Zintis wrote: I'm trying to port Direct Connect Text Client for Broadcom 2.4 kernel. It needs Berkeley DB. Although there is a package in repository, it doesn't work -- I'm getting error: "unable to initialize mutex: Function not implemented" This might imply that the package was configured in a different environment than you are running. Did you build the package yourself ? At configure time, the bdb build detects what mutex implementation is available. If it is built somewhere where it finds for example pthread mutexes, but those are not available at runtime, you will get this error. The same error also happens if you configure on a machine with linuxthreads, but run on one with ntpl (not saying that this is your problem, but I've seen this specific bdb error many times in my travels). Berkeley homepage http://www.oracle.com/technology/products/berkeley-db/faq/db_faq.html#12 says: "To avoid this error, explicitly specify the mutex implementation DB should use, with the --with-mutex=MUTEX configuration flag" Does anybody can give a hint what I should write there? While googling, I found (http://fs-prisms.blogspot.com/2007/08/dtn-additional-notes.html) that for DTN it is possible to use "--with-mutex=ARM/gcc-assembly" I'd recommend that you build the bdb package and examine the output from configure when it's run. Feel free to post it here. I wrote some of the bdb mutex implementations way back, so I'm reasonably familiar with the space. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Why oh why...
...do we have such a big mess of patches for madwifi ? I'm just sayin... every time we pick up a new madwifi revision most of the patches need to be re-done. Has anyone tried to put, for example, the stuff that disables debug code, and the multi-binary stuff back into the upstream code ? Just seems like a strange way to make software (imho) to be spinning on these patches constantly, or alternatively failing to pick up new madwifi revisions because it's too much work to sync up. Patches that are actual bug fixes, not already in the upstream are a fine thing of course. They can be dropped as they are incorporated into madwifi. I'd be happy to work on this. Anyone tried to attack this issue already ? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Why oh why...
Felipe Maya wrote: > e-mail to [EMAIL PROTECTED] > e-mail what exactly ? Or are you just saying that's the way to ask the madwifi developers if we can add our stuff to their code ? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Berekely DB porting
Zintis wrote: I was more like surprised that bdb package is in repository but doesnt works Welcome to the world of open source :) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
