Re: [OpenWrt-Devel] Buffalo WZR-HP-G450H support question
On 2012-01-25 8:19 PM, Felix Fietkau wrote: On 2012-01-25 6:38 PM, Gregory Finch wrote: On 2012-01-24 6:57 AM, Jo-Philipp Wich wrote: Hi, Specifically, I'm lacking the ability to change channels (the important part) option channel ? and have no ability to control antenna chains or adjust power. option txpower, option rxantenna and option txantenna? What can I do to help improve this support, or who can I help? You could start elaborating on the actual problems. ~ Jow Learned alot more about how the config works in OpenWRT. option channel works exactly as advertised, I was trying to change it with iw without any luck. option txpower works properly, limits at 20dBm, which is correct for this hardware/reg domain. I need to play with the antenna options more to figure out which is which out of the three (I'm assuming it's a bitmask, 3 antennas, 7 options) With the power setting, if I have it set at 20dBm (the max), using my non-scientific testing with WiFi Analyser on my phone I read -45 to -50 dB at about 2 feet from the device. Comparing this to a couple of other Dlink devices running their OEM software, at the same distance my phone reads -25 to -30 dB. Is there an amplifier in the Buffalo device that my or may not be switched on? I'm guessing that the power limit in the eeprom is based on having the amplifier on. It just seems like a large power difference that I am measuring. There's a known problem with the power output on this device, which appears to be unrelated to any eeprom limitations. I'm currently working on resolving this. Should be fixed in current SVN trunk. Please test. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] LG-VL600
I noticed that someone added support for the LG-VL600 usb modem has anyone had success talking to it or getting it to connect. I just get a ttyACM0 port but I believe there should be another DATA port. Any help would be greatly appreciated --Dan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] MMnet1000 update to kernel 3.2.1
Sorry for the late response. On Jan 23, 2012 4:48 PM, Przemysław Rudy pru...@o2.pl wrote: On 23.01.2012 15:30, Jonas Gorski wrote: [...] This all belongs into a seperate patch and has nothing to do with updating at91 to 3.2.1 (which you also do in this patch). ok, as 'original' MMnet1000 patch is not included in the tree my idea was to do it from scratch to replace the previous/base patch. If I get your point correctly, at first the previous patch should be applied, then the new one should include only updates since then. No, updated full patches are fine. The problem is if the patch has changes that affect other targets/parts, like your update to 3.2.1. Unless you mean this patch is supposed to update only MMnet1000 to 3.2.1, then this patch clearly doesn't and implicitly updates most other subtargets to 3.2.1, too. I don't think you will be able to just have on subtarget on 3.2 and the others on 2.6.38, since the patches won't apply to both. Yes, it does not seem to be possible without touching other targets. I propose an update to 3.2.1 (incremental from original patch) that will be put on hold on the mail list till other targets are ready. What about: - 1st patch - incremental (from old patch) that covers only kernel+config - 2nd patch - changes to current OpenWrt target allowing the 1st patch to be used (but will break other targets) Is that fine? Not quite. You should create two separate patches, one generic for updating at91 to 3.2 (without breaking other subtargets), and one adding MMnet1000 support. Whether you let the MMnet1000 support depend on the 3.2 patch being applied or the other way round is up to you. Putting patches on hold won't work, by the time it should be applied it likely doesn't apply anymore. You will need to regularly update and resend your patches until they get applied. So please resubmit this patch split up into the two mentioned. Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] rngd patch proposal
Hi,
I've been playing around with rngd for a bit, and came up with
the following patch.
- Add -x to allow startup without /dev/hw_random being available
- Add usleep(1500) to main loop so it doesn't grab 100% cpu if
/dev/hwrandom is lost
- Complain to syslog
Please comment,
- marcel
--- rng-tools-3/rngd.c-org 2012-01-25 20:56:21.0 +0100
+++ rng-tools-3/rngd.c 2012-01-27 10:45:50.0 +0100
@@ -77,6 +77,8 @@
{ background, 'b', 0, 0, Become a daemon (default) },
+ { soft-fail, 'x', 0, 0, Soft fail file input (i.e. keep trying if
open() fails) },
+
{ random-device, 'o', file, 0,
Kernel device used for random number output (default: /dev/random)
},
@@ -104,12 +106,15 @@
.fill_watermark = 2048,
.daemon = 1,
.enable_tpm = 1,
+ .soft_fail = 0,
};
struct arguments *arguments = default_arguments;
static struct rng rng_default = {
.rng_name = /dev/hw_random,
.rng_fd = -1,
+ .valid = 0,
+ .last_invalid = 0,
.xread = xread,
.fipsctx= NULL,
.next = NULL,
@@ -118,6 +123,8 @@
static struct rng rng_tpm = {
.rng_name = /dev/tpm0,
.rng_fd = -1,
+ .valid = 0,
+ .last_invalid = 0,
.xread = xread_tpm,
.fipsctx= NULL,
.next = NULL,
@@ -137,6 +144,9 @@
case 'r':
rng_default.rng_name = arg;
break;
+ case 'x':
+ arguments-soft_fail = 1;
+ break;
case 't': {
float f;
if (sscanf(arg, %f, f) == 0)
@@ -210,13 +220,36 @@
for (;;) {
struct rng *iter;
- for (iter = rng_list; iter; iter = iter-next)
- {
- retval = iter-xread(buf, sizeof buf, iter);
- if (retval == 0)
- update_kernel_random(random_step,
-poll_timeout, buf,
-iter-fipsctx);
+ int n = 0;
+
+ for (iter = rng_list; iter; iter = iter-next) {
+ if (iter-valid == -1 (iter-last_invalid + 10) =
time(NULL)) {
+ iter-valid = 0;
+ message(LOG_DAEMON|LOG_ERR,
+ Re-enable %s\n, iter-rng_name);
+ }
+ if (iter-valid == 0)
+ n++;
+ }
+ if (n == 0)
+ usleep(1500);
+ if (n != 0) {
+ for (iter = rng_list; iter; iter = iter-next) {
+ if (iter-valid == 0) {
+ retval = iter-xread(buf, sizeof buf,
iter);
+ if (retval == 0) {
+
update_kernel_random(random_step,
+ poll_timeout, buf,
+ iter-fipsctx);
+ }
+ else {
+ iter-valid = -1;
+ iter-last_invalid = time(NULL);
+ message(LOG_DAEMON|LOG_ERR,
+ Error reading from
device %s, skipping it for a bit\n, iter-rng_name);
+ }
+ }
+ }
}
}
}
--- rng-tools-3/rngd.h-org 2012-01-25 20:56:26.0 +0100
+++ rng-tools-3/rngd.h 2012-01-27 10:46:01.0 +0100
@@ -29,6 +29,7 @@
#include stdint.h
#include stdio.h
#include syslog.h
+#include time.h
#include fips.h
@@ -42,6 +43,7 @@
int daemon;
int enable_tpm;
+ int soft_fail;
};
extern struct arguments *arguments;
@@ -50,6 +52,9 @@
char *rng_name;
int rng_fd;
+ int valid;
+ time_t last_invalid;
+
int (*xread) (void *buf, size_t size, struct rng *ent_src);
fips_ctx_t *fipsctx;
--- rng-tools-3/rngd_entsource.c-org2012-01-26 13:29:21.0 +0100
+++ rng-tools-3/rngd_entsource.c2012-01-27 10:46:28.0 +0100
@@ -52,7 +52,11 @@
size_t off = 0;
ssize_t r;
- while (size 0) {
+ if (ent_src-rng_fd == -1) {
+ ent_src-rng_fd = open(ent_src-rng_name, O_RDONLY);
+ }
+
+ while (size 0 ent_src-rng_fd != -1) {
do {
r = read(ent_src-rng_fd, buf + off, size);
} while ((r == -1) (errno ==
[OpenWrt-Devel] [PATCH] [packages] ndppd: initial import (release 0.2.1)
Hi,
here is a patch to add a package for ndppd:
ndppd, or NDP Proxy Daemon, is a daemon that proxies NDP (Neighbor Discovery
Protocol) messages between interfaces. ndppd currently only supports
Neighbor Solicitation Messages and Neighbor Advertisement Messages.
The ndp_proxy provided by Linux doesn't support listing proxies, and only
hosts are supported. No subnets. ndppd solves this by listening for
Neighbor Solicitation messages on an interface, then query the internal
interfaces for that target IP before finally sending a Neighbor
Advertisement message.
http://www.priv.nu/projects/ndppd/
I tested it and it works fine. I am willing to maintain it.
Note that this my first C++ package and it took a lot of trial and error to get
the Build/Compile target working. Any feedback would be much welcome.
Best regard,
--
Gabriel
From 689b4a52af2e25e3574d0dca7cc5e63ed100c50a Mon Sep 17 00:00:00 2001
From: Gabriel Kerneis kern...@pps.jussieu.fr
Date: Fri, 27 Jan 2012 15:35:14 +0100
Subject: [PATCH] [packages] ndppd: initial import (release 0.2.1)
---
ipv6/ndppd/Makefile | 62 +++
ipv6/ndppd/files/ndppd.init | 16 +++
2 files changed, 78 insertions(+), 0 deletions(-)
create mode 100644 ipv6/ndppd/Makefile
create mode 100644 ipv6/ndppd/files/ndppd.init
diff --git a/ipv6/ndppd/Makefile b/ipv6/ndppd/Makefile
new file mode 100644
index 000..08ccc76
--- /dev/null
+++ b/ipv6/ndppd/Makefile
@@ -0,0 +1,62 @@
+#
+# Copyright (C) 2007-2011 OpenWrt.org
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=ndppd
+PKG_VERSION:=0.2.1
+PKG_RELEASE:=1
+
+PKG_SOURCE:=$(PKG_NAME)_$(PKG_VERSION).tar.gz
+PKG_SOURCE_URL:=http://www.priv.nu/projects/ndppd/files/
+PKG_MD5SUM:=9b65a8cccfce8689f0c1c410c20b4790
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/ndppd
+ SECTION:=ipv6
+ CATEGORY:=IPv6
+ TITLE:=NDP Proxy Daemon
+ URL:=http://www.priv.nu/projects/ndppd/
+ MAINTAINER:=Gabriel Kerneis kern...@pps.jussieu.fr
+ DEPENDS:=+kmod-ipv6 +confuse +uclibcxx
+endef
+
+define Package/ndppd/description
+ ndppd, or NDP Proxy Daemon, is a daemon that proxies NDP (Neighbor Discovery
+ Protocol) messages between interfaces. ndppd currently only supports Neighbor
+ Solicitation Messages and Neighbor Advertisement Messages.
+
+ The ndp_proxy provided by Linux doesn't support listing proxies, and only hosts
+ are supported. No subnets. ndppd solves this by listening for Neighbor
+ Solicitation messages on an interface, then query the internal interfaces for
+ that target IP before finally sending a Neighbor Advertisement message.
+endef
+
+define Package/ndppd/conffiles
+/etc/ndppd.conf
+endef
+
+define Build/Compile
+ $(MAKE) -C $(PKG_BUILD_DIR) \
+ CXX=$(TARGET_CXX) \
+ CXXFLAGS=$(TARGET_CPPFLAGS) $(TARGET_CXXFLAGS) -fno-builtin -fno-rtti -nostdinc++ \
+ -I$(STAGING_DIR)/usr/include/uClibc++ -I$(LINUX_DIR)/include \
+ LDFLAGS=$(TARGET_LDFLAGS) \
+ LIBS=-nodefaultlibs -luClibc++ -lconfuse \
+ ndppd
+endef
+
+define Package/ndppd/install
+ $(INSTALL_DIR) $(1)/usr/sbin
+ $(INSTALL_BIN) $(PKG_BUILD_DIR)/ndppd $(1)/usr/sbin/
+ $(INSTALL_DIR) $(1)/etc/init.d
+ $(INSTALL_BIN) ./files/ndppd.init $(1)/etc/init.d/ndppd
+ $(INSTALL_CONF) $(PKG_BUILD_DIR)/ndppd.conf-dist $(1)/etc/ndppd.conf
+endef
+
+$(eval $(call BuildPackage,ndppd))
diff --git a/ipv6/ndppd/files/ndppd.init b/ipv6/ndppd/files/ndppd.init
new file mode 100644
index 000..4cf0e8a
--- /dev/null
+++ b/ipv6/ndppd/files/ndppd.init
@@ -0,0 +1,16 @@
+#!/bin/sh /etc/rc.common
+# Copyright (C) 2007-2011 OpenWrt.org
+
+START=90
+
+SERVICE_USE_PID=1
+SERVICE_PID_FILE=/var/run/ndppd.pid
+
+start() {
+ mkdir -p /var/run
+ service_start /usr/sbin/ndppd -p $SERVICE_PID_FILE -d
+}
+
+stop() {
+ service_stop /usr/sbin/ndppd
+}
--
1.7.8.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] ar71xx: TL-MR3020: fix board detection, fix missing mandatory package and modify LED behaviour
Am 25.01.2012 08:46, schrieb Gabor Juhos: 2012.01.24. 19:41 keltezéssel, Christian Cier-Zniewski írta: The LED behaviour has also been modified: * The WPS LED is the diag LED now. Aplied with some chages. Unfortunately, you have forgotten one change: --- target/linux/ar71xx/base-files/etc/diag.sh (Revision 29875) +++ target/linux/ar71xx/base-files/etc/diag.sh (Arbeitskopie) @@ -97,7 +97,9 @@ tew-632brp) status_led=tew-632brp:green:status ;; - tl-mr3020 | \ + tl-mr3020-v1) + status_led=tp-link:green:wps + ;; tl-mr3220 | \ tl-mr3420 | \ tl-wa901nd | \ The TL-MR3020 does not have a system LED. Therefore I suggest to assign the WPS led. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] ar71xx: TL-MR3020: fix board detection, fix missing mandatory package and modify LED behaviour
2012.01.27. 20:50 keltezéssel, Christian Cier-Zniewski írta: Am 25.01.2012 08:46, schrieb Gabor Juhos: 2012.01.24. 19:41 keltezéssel, Christian Cier-Zniewski írta: The LED behaviour has also been modified: * The WPS LED is the diag LED now. Aplied with some chages. Unfortunately, you have forgotten one change: --- target/linux/ar71xx/base-files/etc/diag.sh(Revision 29875) +++ target/linux/ar71xx/base-files/etc/diag.sh(Arbeitskopie) @@ -97,7 +97,9 @@ tew-632brp) status_led=tew-632brp:green:status ;; -tl-mr3020 | \ +tl-mr3020-v1) +status_led=tp-link:green:wps +;; tl-mr3220 | \ tl-mr3420 | \ tl-wa901nd | \ The TL-MR3020 does not have a system LED. Therefore I suggest to assign the WPS led. See: https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/base-files/etc/diag.sh#L100 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] support for D-LINK DIR-615 rev. E4
This patch adds support for D-LINK DIR-615 E4 board. It's mostly based
on the existing support for DIR-600 A1, with some changes in the leds
configuration.
It's an updated version of the patch that reliably works on my hw for
about a year (it was built from trunk on Jan 2011). When I decided to
update the firmware and checked for the current support for that device,
I also found previously posted patches by Alexey Loukianov that
mentioned some stability issues. I'm not sure where could be the
difference, the patches are very similar except the wmac led pin number
- I was using 1, and those patches used 17.
Signed-off-by: Vadim Girlin vadimgir...@gmail.com
---
Index: target/linux/ar71xx/files-2.6.39/arch/mips/ar71xx/mach-dir-615-e4.c
===
--- target/linux/ar71xx/files-2.6.39/arch/mips/ar71xx/mach-dir-615-e4.c
(revision 0)
+++ target/linux/ar71xx/files-2.6.39/arch/mips/ar71xx/mach-dir-615-e4.c
(revision 0)
@@ -0,0 +1,183 @@
+/*
+ * D-Link DIR-615 rev. E4 board support
+ *
+ * Copyright (C) 2010 Gabor Juhos juh...@openwrt.org
+ * Copyright (C) 2012 Vadim Girlin vadimgir...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+
+#include asm/mach-ar71xx/ar71xx.h
+
+#include machtype.h
+#include devices.h
+#include dev-m25p80.h
+#include dev-ap91-pci.h
+#include dev-gpio-buttons.h
+#include dev-leds-gpio.h
+#include nvram.h
+
+#define DIR_615_E4_GPIO_LED_WPS0
+#define DIR_615_E4_GPIO_LED_POWER_AMBER1
+#define DIR_615_E4_GPIO_LED_POWER_GREEN6
+#define DIR_615_E4_GPIO_LED_WAN_AMBER 7
+#define DIR_615_E4_GPIO_LED_WAN_GREEN 17
+#define DIR_615_E4_GPIO_LED_LAN1_GREEN 13
+#define DIR_615_E4_GPIO_LED_LAN2_GREEN 14
+#define DIR_615_E4_GPIO_LED_LAN3_GREEN 15
+#define DIR_615_E4_GPIO_LED_LAN4_GREEN 16
+
+#define DIR_615_E4_GPIO_BTN_RESET 8
+#define DIR_615_E4_GPIO_BTN_WPS12
+
+#define DIR_615_E4_KEYS_POLL_INTERVAL 20
+#define DIR_615_E4_KEYS_DEBOUNCE_INTERVAL (3 * DIR_615_E4_KEYS_POLL_INTERVAL)
+
+#define DIR_615_E4_NVRAM_ADDR 0x1f03
+#define DIR_615_E4_NVRAM_SIZE 0x1
+
+#ifdef CONFIG_MTD_PARTITIONS
+static struct mtd_partition dir_615_e4_partitions[] = {
+ {
+ .name = u-boot,
+ .offset = 0,
+ .size = 0x03,
+ .mask_flags = MTD_WRITEABLE,
+ }, {
+ .name = nvram,
+ .offset = 0x03,
+ .size = 0x01,
+ }, {
+ .name = kernel,
+ .offset = 0x04,
+ .size = 0x0e,
+ }, {
+ .name = rootfs,
+ .offset = 0x12,
+ .size = 0x2c,
+ }, {
+ .name = mac,
+ .offset = 0x3e,
+ .size = 0x01,
+ .mask_flags = MTD_WRITEABLE,
+ }, {
+ .name = art,
+ .offset = 0x3f,
+ .size = 0x01,
+ .mask_flags = MTD_WRITEABLE,
+ }, {
+ .name = firmware,
+ .offset = 0x04,
+ .size = 0x3a,
+ }
+};
+#endif /* CONFIG_MTD_PARTITIONS */
+
+static struct flash_platform_data dir_615_e4_flash_data = {
+#ifdef CONFIG_MTD_PARTITIONS
+ .parts = dir_615_e4_partitions,
+ .nr_parts = ARRAY_SIZE(dir_615_e4_partitions),
+#endif
+};
+
+
+static struct gpio_led dir_615_e4_leds_gpio[] __initdata = {
+ {
+ .name = dir-615-e4:green:power,
+ .gpio = DIR_615_E4_GPIO_LED_POWER_GREEN,
+ }, {
+ .name = dir-615-e4:amber:power,
+ .gpio = DIR_615_E4_GPIO_LED_POWER_AMBER,
+ }, {
+ .name = dir-615-e4:green:wan,
+ .gpio = DIR_615_E4_GPIO_LED_WAN_GREEN,
+ .active_low = 1,
+ }, {
+ .name = dir-615-e4:amber:wan,
+ .gpio = DIR_615_E4_GPIO_LED_WAN_AMBER,
+ }, {
+ .name = dir-615-e4:green:lan1,
+ .gpio = DIR_615_E4_GPIO_LED_LAN1_GREEN,
+ .active_low = 1,
+ }, {
+ .name = dir-615-e4:green:lan2,
+ .gpio = DIR_615_E4_GPIO_LED_LAN2_GREEN,
+ .active_low = 1,
+ }, {
+ .name = dir-615-e4:green:lan3,
+
Re: [OpenWrt-Devel] [PATCH] Fix avahi build problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 21.11.2011 14:48, schrieb Mike Brady: ... Packages that don't require D-BUS support are compiled with D-BUS support disabled by default, keeping the build as small as possible. Support for D-BUS can be selected if desired. Selecting packages that require D-BUS support -- avahi-utils or libavahi-client -- will automatically cause all packages to be built with D-BUS support and will add the D-BUS package to the build. Good so far, I'm using avahi heavily but back in Nov this sounded well to me, no reason to complain so nothing to say ;) Now having update to latest trunk I ran into one thing: When putting avahi-daemon (no dbus needed there at first) into the base image and building the remainder (libavahi-client etc.) as addon-packages to get post-installed as needed, the image-included avahi-daemon won't run. Clear so far, it was build with dbus but there is no lib/dbus. Wouldn't it be neater to have two packages there ? Something like avahi-daemon (no dbus compiled in) avahi-daemon-dbus So one can choose to include avahi but without all the overhead and still install the dbus-support later on as required. i.e. like it's done with the pulseaudio-daemon/pulseausio-daemon-avahi packages best regards Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8jSS0ACgkQaWRHV2kMuAJ7BACgu60huijHZtuOx5buFkJpbu1R 5YMAoJvOqfZ2l8773uO/w15fyLmKnr7h =jnGD -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/1] linux 3.3: geode platform includes extensive enhancements
Linux 3.3 will include 3 patches I've contributed including a significant rewrite of the alix2 driver, plus geos and net5501 platform drivers. This prepares OpenWRT for these changes to come downstream. Signed-off-by: Philip Prindeville phil...@redfish-solutions.com Index: target/linux/x86/alix2/config-default === --- target/linux/x86/alix2/config-default (revision 29805) +++ target/linux/x86/alix2/config-default (working copy) @@ -22,3 +22,6 @@ # CONFIG_CS5535_CLOCK_EVENT_SRC is not set CONFIG_PATA_CS5536=y CONFIG_ALIX=y +CONFIG_DMI=y +# CONFIG_DMI_SYSFS is not set +# CONFIG_DMIID is not set Index: target/linux/x86/config-default === --- target/linux/x86/config-default (revision 29805) +++ target/linux/x86/config-default (working copy) @@ -455,4 +455,6 @@ # CONFIG_BATTERY_BQ20Z75 is not set # CONFIG_TRANSPARENT_HUGEPAGE is not set # CONFIG_ALIX is not set +# CONFIG_GEOS is not set +# CONFIG_NET5501 is not set # CONFIG_SAMSUNG_Q10 is not set Index: target/linux/x86/geos/config-default === --- target/linux/x86/geos/config-default(revision 29805) +++ target/linux/x86/geos/config-default(working copy) @@ -1,32 +1,27 @@ # CONFIG_ACPI is not set CONFIG_DMI=y CONFIG_DMIID=y +CONFIG_PROCESSOR_SELECT=y CONFIG_CPU_SUP_AMD=y -CONFIG_GEODE_MFGPT_TIMER=y -# CONFIG_GEODE_WDT is not set +CONFIG_GPIOLIB=y +CONFIG_GPIO_SYSFS=y +CONFIG_DEBUG_BUGVERBOSE=y CONFIG_HAVE_PERF_EVENTS=y +CONFIG_GENERIC_GPIO=y CONFIG_HWMON=y # CONFIG_HWMON_DEBUG_CHIP is not set -# CONFIG_ISA is not set -# CONFIG_INPUT is not set -# CONFIG_KEYBOARD_ATKBD is not set # CONFIG_M486 is not set CONFIG_MGEODE_LX=y # CONFIG_MOUSE_PS2 is not set # CONFIG_PCIEPORTBUS is not set CONFIG_PCSPKR_PLATFORM=y -CONFIG_PROCESSOR_SELECT=y # CONFIG_SCx200 is not set # CONFIG_SERIO_I8042 is not set # CONFIG_SERIO_LIBPS2 is not set CONFIG_X86_DEBUGCTLMSR=y -# CONFIG_X86_DS is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_INTERNODE_CACHE_SHIFT=5 CONFIG_X86_L1_CACHE_SHIFT=5 -CONFIG_X86_TSC=y -CONFIG_X86_USE_3DNOW=y -CONFIG_X86_USE_PPRO_CHECKSUM=y -CONFIG_GPIOLIB=y # CONFIG_CS5535_CLOCK_EVENT_SRC is not set CONFIG_PATA_CS5536=y +CONFIG_GEOS=y Index: target/linux/x86/geos/base-files/etc/hotplug.d/button/50-reboot === --- target/linux/x86/geos/base-files/etc/hotplug.d/button/50-reboot (revision 0) +++ target/linux/x86/geos/base-files/etc/hotplug.d/button/50-reboot (revision 0) @@ -0,0 +1,13 @@ +#!/bin/sh + +logger -t button -p daemon.info $BUTTON/$ACTION + +case $BUTTON/$ACTION in + +reset/released) + reboot -f + ;; + +esac + +exit 0 Property changes on: target/linux/x86/geos/base-files/etc/hotplug.d/button/50-reboot ___ Added: svn:executable + * Index: target/linux/x86/geos/base-files/etc/config/system === --- target/linux/x86/geos/base-files/etc/config/system (revision 0) +++ target/linux/x86/geos/base-files/etc/config/system (revision 0) @@ -0,0 +1,27 @@ + +config system + option hostname OpenWrt + option timezone UTC + +config rdate + option interface wan + +config led + option default 0 + option name LAN + option sysfs'geos:1' + option trigger netdev + option mode 'tx rx' + option dev 'br-lan' + +config led + option default 0 + option name WiFi + option sysfs'geos:2' + option trigger 'phy0tpt' + +config led + option default 0 + option name Health + option sysfs'geos:3' + option trigger 'heartbeat' Index: target/linux/x86/geos/target.mk === --- target/linux/x86/geos/target.mk (revision 29805) +++ target/linux/x86/geos/target.mk (working copy) @@ -15,6 +15,10 @@ kmod-cfg80211 kmod-mac80211 \ kmod-mppe kmod-pppoe kmod-pppoa kmod-pppol2tp \ kmod-ath kmod-ath5k kmod-ath9k \ +kmod-leds-gpio kmod-input-gpio-keys-polled \ +kmod-button-hotplug \ +kmod-ledtrig-heartbeat kmod-ledtrig-gpio \ +kmod-ledtrig-netdev kmod-ledtrig-netfilter \ kmod-cpu-msr \ soloscli linux-atm br2684ctl bridge ppp ppp-mod-pppoa \ pppdump pppstats \ Index: target/linux/x86/net5501/config-default === --- target/linux/x86/net5501/config-default (revision 29805) +++ target/linux/x86/net5501/config-default (working copy) @@ -1,42 +1,24 @@ -CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-ecx -fcall-saved-edx +CONFIG_PROCESSOR_SELECT=y
Re: [OpenWrt-Devel] Let's fix the OpenWrt patch acceptance problem!
On 1/25/12 3:50 PM, Philip Prindeville wrote: [snip] My problem is the opposite. I use x86 hardware because it's what I have, and ath5k hardware for the same reason. I'm told that my patches languish because they are for 2.6.39.4 (or whatever) and I'm encouraged to go to a newer kernel... but I can't because all of the churn with the ath9k goes untested and tends to be extremely destabilizing to the ath5k drivers. Hence I'm *forced* to use the 2.6.39.x if I want a machine that even boots. One other suggestion I'd make to improve patch acceptance is this: let's have a more concrete set of policies about patch requirements. Recently I submitted a patch for 3.2 and it was rejected because it didn't include versions for early kernel releases (2.6.39, 3.0, and 3.1). Another patch I suggested that was for 2.6.39 which I had extensively tested was rejected because the person I had asked was tired of maintaining so many versions and wanted to kill off the older versions. So what the right thing to do depends heavily on who you ask. It doesn't need to be like this. Let's have a straightforward policy like: (1) a patch MUST support the latest kernel; (2) it SHOULD support all versions going back to the STABLE version; Since (2) would only be a recommendation, it shouldn't be a blocking requirement. -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt-Users] Linksys WRT150N wireless supported in 10.03.1?
Thanks for looking at my logs. I just installed the trunk that was compiled today (r29915, thanks to whoever ran that build) and SSH seems to be behaving, so my SSH issues may have just been a fluke. Wireless still fails at boot until I run the wifi debugging command as shown below. I tried running just wifi and even though both commands claim to use /var/run/hostapd-phy0.conf for the config, something is different. When I run killall -9 hostapd then wifi I get told: Configuration file: /var/run/hostapd-phy0.conf and Using interface wlan0 with hwaddr MACADDRESS and ssid 'OpenWrt'wifi is still rejecting connections. When I run killall -9 hostapd; /usr/sbin/hostapd -dd /var/run/hostapd-phy0.conf /tmp/hostapd.log it works right away. One oddity, I see what may be an extraneous entry in ifconfig called mon.wlan0: Before the debug piece above: mon.wlan0 Link encap:UNSPEC HWaddr 00-88-88-88-00-2A-00-00-00-00-00-00-00-00-00-00 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:402 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:32 RX bytes:38292 (37.3 KiB) TX bytes:0 (0.0 B) wlan0 Link encap:Ethernet HWaddr 00:18:F8:D7:BB:35 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:10 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:32 RX bytes:0 (0.0 B) TX bytes:1516 (1.4 KiB) After: mon.wlan0 Link encap:UNSPEC HWaddr 00-88-88-88-00-2A-00-00-00-00-00-00-00-00-00-00 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:136 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:32 RX bytes:13650 (13.3 KiB) TX bytes:0 (0.0 B) wlan0 Link encap:Ethernet HWaddr 00:88:88:88:00:2A UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:64 errors:0 dropped:0 overruns:0 frame:0 TX packets:119 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:32 RX bytes:7058 (6.8 KiB) TX bytes:15905 (15.5 KiB) Should mon.wlan0 be there? Why do the errors all go away? Thanks Aaron Z - Original Message - From: Hauke Mehrtens ha...@hauke-m.de To: Aaron Z aar...@pls-net.org Cc: OpenWrt Development List openwrt-devel@lists.openwrt.org Sent: Monday, January 23, 2012 4:38:16 PM Subject: Re: [OpenWrt-Users] Linksys WRT150N wireless supported in 10.03.1? Hi Aaron, thanks for the detailed report. With a quick look I was unable to see anything suspicious in the logs. I will try to reproduce your problems on one of my devices. Hauke On 01/22/2012 07:49 PM, Aaron Z wrote: Got the wireless to work today. I followed the directions at http://wiki.openwrt.org/doc/devel/debugging and ran killall -9 hostapd; /usr/sbin/hostapd -dd /var/run/hostapd-phy0.conf /tmp/hostapd.log from a SSH session, then tried to connect. Before I ran it, I would get a connection failed message as soon as I tried to connect. After I ran the above command, it failed once, then connected on the 2nd try. That log is attatched as WiFiLog1.txt. I rebooted by pulling the power cable (I am fairly certain that the reboot command worked in 10.03.1, but cannot say for certain) and I tried connecting to the wifi again. I got a connection failed message as soon as I tried to connect. After I ran the aforementioned command, I was able to connect immediately on the first try. That log is attached as WiFiLog2.txt. Is there a more effective and/or less intrusive way to log this data? I looked in /tmp/log, but the only things I see are lastlog and wtmp both of which are 0 byte files that claim to have been created on 1/1/1970. SSH and SCP both worked fine under 10.03.1. No lockups or reconnects that I remember. Package installation also worked. I was able to install the pciutils package without any drama. Let me know if I can provide any more data to help. Thanks Aaron Z - Original Message - From: Hauke Mehrtens ha...@hauke-m.de To: Aaron Z aar...@pls-net.org Cc: OpenWrt Development List openwrt-devel@lists.openwrt.org Sent: Sunday, January 22, 2012 8:16:52 AM Subject: Re: [OpenWrt-Users] Linksys WRT150N wireless supported in 10.03.1? Hi Aaron, On 01/22/2012 04:54 AM, Aaron Z wrote: Resending as I used the wrong from address last time and it bounced. hmm at least I got your mails. It loaded and booted, but I am seeing some oddities. Not sure if these are related to being bleeding edge or what, but they are noticeable: The patch did what it was supposed to and I will merge it into trunk and Backfire branch. The other problems seam to be related to some other
