Re: [OpenWrt-Devel] Let's fix the OpenWrt patch acceptance problem!
On 01/25/2012 03:46 AM, Philip Prindeville wrote: For those of us that submit fixes that then languish for months before being committed, wouldn't that mean having to constantly rebase them? i don't think svn as any magic to deal with it either... -- bye, p. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Let's fix the OpenWrt patch acceptance problem!
Hello Felix, Does this proposal make sense? Do we have any volunteers that are willing to organize and take care of maintaining the tree and compile testing and reviewing the incoming changes? I can offer to help with brcm47xx, x86. Also, I working on webif package (just for your interest). With best regards Christoph -- Linux User Group Wernigerode http://www.lug-wr.de/ signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] wait for blockdevice mtd2block (useful for usbboot)
Hello,
I'm working on x86 using usb for boot. It works for me if usb and usb-storage
drivers enabled via make kernel_menuconfig.
One thing I had to fix for get it working: mtd2block does not long enough
until usb has been up. This patch was made against 2.6.32 at 10.03 (put in
target/linux/generic-2.6/patches-2.6.32).
This is same as I wrote at https://dev.openwrt.org/ticket/9780
The second one (068-block2mtd_probe.patch, adds the wait for device probe) was
missing on ticket.
The patch is based on the code at
http://permalink.gmane.org/gmane.linux.drivers.mtd/26384 (by Tobias
Diedrich).
Maybe we find a way to integrate usbboot options (enable usb+usb-storage
directly into kernel if usb boot enabled via option). I'll have a look on
that later.
With best regards
Christoph
--
Linux User Group Wernigerode
http://www.lug-wr.de/) but
--- a/drivers/mtd/devices/block2mtd.c
+++ b/drivers/mtd/devices/block2mtd.c
@@ -268,6 +268,7 @@ static int _open_bdev(struct block2mtd_d
/* We might not have rootfs mounted at this point. Try
to resolve the device name by other means. */
+ wait_for_device_probe();
dev_t devt = name_to_dev_t(dev-devname);
if (devt) {
bdev = open_by_devnum(devt, FMODE_WRITE | FMODE_READ);
--- a/drivers/mtd/devices/block2mtd.c.orig 2011-07-22 10:17:24.006187073 +0200
+++ a/drivers/mtd/devices/block2mtd.c 2011-07-22 10:48:03.706185480 +0200
@@ -18,6 +18,8 @@
#include linux/buffer_head.h
#include linux/mutex.h
#include linux/mount.h
+#include linux/delay.h
+#include linux/kthread.h
#define ERROR(fmt, args...) printk(KERN_ERR block2mtd: fmt \n , ## args)
#define INFO(fmt, args...) printk(KERN_INFO block2mtd: fmt \n , ## args)
@@ -475,7 +477,31 @@
#endif
-static int block2mtd_setup2(const char *val)
+struct block2mtd_setupasync_params {
+ char *name;
+ int erase_size;
+ char *mtdname;
+};
+
+static int block2mtd_setupasync(void *p)
+{
+ struct block2mtd_setupasync_params *params = p;
+ int i;
+
+ printk(KERN_WARNING block2mtd: spawned kernel thread for async waiting on '%s'\n, params-name);
+ for (i=0; i20; i++) {
+ msleep(1000);
+
+if (add_device(params-name, params-erase_size, params-mtdname) != NULL)
+ break;
+ }
+ kfree(params-name);
+ kfree(params);
+
+ return 0;
+}
+
+static int block2mtd_setup2(const char *val, int async)
{
char buf[80 + 12 + 80]; /* 80 for device, 12 for erase size, 80 for name */
char *str = buf;
@@ -483,6 +509,7 @@
char *name;
size_t erase_size = PAGE_SIZE;
int i, ret;
+ struct block2mtd_setupasync_params *params;
if (strnlen(val, sizeof(buf)) = sizeof(buf))
parse_err(parameter too long);
@@ -512,7 +539,33 @@
if (token[2] (strlen(token[2]) + 1 80))
parse_err(mtd device name too long);
- add_device(name, erase_size, token[2]);
+ if (add_device(name, erase_size, token[2]) != NULL)
+ return 0;
+
+ params = kzalloc(sizeof(struct block2mtd_setupasync_params), GFP_KERNEL);
+ if (!params)
+ return 0;
+
+ params-name = kmalloc(strlen(name)+1, GFP_KERNEL);
+ params-erase_size = erase_size;
+ if (!params-name) {
+ kfree(params);
+ return 0;
+ }
+
+ memcpy(params-name, name, strlen(name)+1);
+
+ params-mtdname = kmalloc(strlen(token[2])+1, GFP_KERNEL);
+
+ if (!params-mtdname) {
+ kfree(params);
+ return 0;
+ }
+
+ memcpy(params-mtdname, token[2], strlen(token[2])+1);
+
+ if (async)
+ kthread_run(block2mtd_setupasync, params, block2mtd/setupasync);
return 0;
}
@@ -521,7 +574,7 @@
static int block2mtd_setup(const char *val, struct kernel_param *kp)
{
#ifdef MODULE
- return block2mtd_setup2(val);
+ return block2mtd_setup2(val, 0);
#else
/* If more parameters are later passed in via
/sys/module/block2mtd/parameters/block2mtd
@@ -529,7 +582,7 @@
we can parse the argument now. */
if (block2mtd_init_called)
- return block2mtd_setup2(val);
+ return block2mtd_setup2(val, 0);
/* During early boot stage, we only save the parameters
here. We must parse them later: if the param passed
@@ -554,7 +607,7 @@
#ifndef MODULE
if (strlen(block2mtd_paramline))
- ret = block2mtd_setup2(block2mtd_paramline);
+ ret = block2mtd_setup2(block2mtd_paramline, 1);
block2mtd_init_called = 1;
#endif
signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Let's fix the OpenWrt patch acceptance problem!
On Wed, Jan 25, 2012 at 3:46 AM, Philip Prindeville philipp_s...@redfish-solutions.com wrote: On 1/24/12 6:06 AM, Jonathan McCrohan wrote: I also see svn as part of the problem. I think a move towards the linux-kernel development model would be a great benefit. Using git would allow users to make many small fixes in their own tree and send single a pull request for fixes to x,y and z to a member of the patch review team for ACK or NAK who can then commit to master. Hopefully this will result in fewer stray patches. The original user will then show up in git blame and will make tracing errors far easier. Currently, unless you have commit rights, everything comes from one of the few core developers and you have to manually look up the changeset to figure out who is responsible for it. For those of us that submit fixes that then languish for months before being committed, wouldn't that mean having to constantly rebase them? Certainly, I do not want to fork this conversation further, and I would hope that if the time between submittal and application can be brought down that this ongoing problem will be reduced. It IS a pita however, and like many I'm willing to volunteer to help, and I've seen a few suggestions (like using git pulls from temporary repos to preserve ownership) go by that look like further improvements on the process. However, I would also like to find ways to deal with my other comment on this thread: A second, large problem (in my mind), is that I would like to find a process for getting stuff upstream into the mainline kernel. Returning to handling the patch backlog: One way to perhaps help this is for the overall schedule to be more widely publicised and to work on more of a time based manner. In my case I've been trying to adhere to the kernel release schedule + .1 + X, where .1 is the first followup to the 'stable' kernel release, where X is the delta that it seems to take between a release and patches appearing. The ar71xx 3.1 process had 3? 4? patch sets go by that never made it into openwrt proper (and I rebased each time), and the 3.2 patch set landed a few days ago without (as best as I recall) public review. I'm delighted that it appears to work, but confess to having been a bit surprised. (I have been out of the loop for several weeks however) Would adding a 'Tested-by' email, to patch sets going by, be a helpful addition? It seems that also finding a way to track coverage sanely would be good addition, like: Tested-by: dave.t...@gmail.com Coverage: ag71xx Or on a proposed patch from a developer unable to fully test: Coverage-needed: mips, arm, x86 -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Dave Täht SKYPE: davetaht US Tel: 1-239-829-5608 FR Tel: 0638645374 http://www.bufferbloat.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] x86 sysupgrade
Hi, On 23.01.2012 07:28, Philip Prindeville wrote: For those of us using x86-based platforms we'd like to have a way to do in-place upgrades without losing configuration state. How do you perform your updates at the moment? I ask because the only way to write a new image to my Alix 2D13 ist to use dd. Sysupgrade (with and without keeping configfiles) does not write the image. This seems to be a problem only with the squashfs image. Martin ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add mostly complete support for Sitecom WL-341 v3 and other Sercomm IP1006RRv2 based boards
On 24 January 2012 03:39, Marco Antonio Mauro marcu...@gmail.com wrote: Leds are tested in output mode which you are skipping. If you are testing leds only you should be skipping input mode, not output, and see which led blinks (it should blink 3 times if you don't interrupt it). The thing is that it won't change gpio if I don't skip input and output manually How is that? Did you wait for it to change the state (blink) 3 times (you'll see the value of the pin printed 3 times)? Some pins error out even though no modules apart from network are loaded. I'm trying to find those too and once done I'll update the patch -- you can disregard this one. Forget about those errors - these are the pins which are already occupied. Testing for buttons you should press it, while in input mode, and see if pin state changes. Buttons should work as is as I found the pins for them in the source code released by the manufacturer. Should and work are completely different things ;) Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: Rework ramips_eth to not require irqsave locking anymore
On 23 January 2012 16:26, Helmut Schaa helmut.sc...@googlemail.com wrote: Well, ok, I'll retest everything again (a bit later) and let you know the results. Ok, thanks. It could be that you were right that my testing environment/hardware is not good enough. When I started to use iperf wireless card (well, probably the driver) in my laptop behaved very bad. It hanged pretty frequently (~20% of the time) and speed tests were very weird - sometimes I was getting stable 65 Mbit/s but sometimes it was jumping from 20 to 65 per test. Device placement and environment was the same all the time. The thing is that I have to use proprietary broadcom driver for this card (BCM4321) to get n mode. And it's very unstable. So, for now, I can't say anything useful. Probably I should get some good and supported 802.11n hardware. Any advises for miniPCI and/or miniPCI express cards? Atheros based? Ralink? Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] x86 sysupgrade
I'm actually using sysupgrade on an alix 2c board and it works. I'm not keeping the actual configuration instead i have a script that: 1. downloads a new configuration from a server (a tar.gz) 2. downloads the new image 3. runs sysupgrade with the option to use an external archive for the configuration Basically is my way of doing a reset to factory configuration. On 25/01/2012 15:58, Martin Roecker wrote: Hi, On 23.01.2012 07:28, Philip Prindeville wrote: For those of us using x86-based platforms we'd like to have a way to do in-place upgrades without losing configuration state. How do you perform your updates at the moment? I ask because the only way to write a new image to my Alix 2D13 ist to use dd. Sysupgrade (with and without keeping configfiles) does not write the image. This seems to be a problem only with the squashfs image. Martin ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Roberto Riggio, Ph.D. CREATE-NET Network Security Solutions for Pervasive Computing Systems (iNSPIRE) Senior Researcher Via alla Cascata 56/D - 38123 Povo Trento (Italy) e-mail: roberto.rig...@create-net.org Tel: (+39) 0461 408400 - interno/extension 708 Fax: (+39) 0461 421157 www.create-net.org/~rriggio The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited according to the Italian Law 196/2003 of the Legislature. If you received this in error, please contact the sender and delete the material from any computer. Le informazioni contenute in questo messaggio di posta elettronica e nei file allegati sono da considerarsi strettamente riservate. Il loro utilizzo e' consentito esclusivamente al destinatario del messaggio, per le finalita' indicate nel messaggio stesso. Qualora riceveste questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla cancellazione del messaggio stesso dal Vostro sistema. Trattenere il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalita' diverse, costituisce comportamento contrario ai principi dettati dal D. Lgs. 196/2003. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Buffalo WZR-HP-G450H support question
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. -Greg signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ar71xx: add support for Compex WPE72/WPE72NX
This patch adds support for Compex WPE72 bare board and Compex WPE72NX
Indoor Access Point.
Signed-off-by: Johnathan Boyce jon.bo...@globalreach.eu.com
mailto:jon.bo...@globalreach.eu.com
---
Index: target/linux/ar71xx/files/arch/mips/ar71xx/mach-wpe72.c
===
--- target/linux/ar71xx/files/arch/mips/ar71xx/mach-wpe72.c (revision 0)
+++ target/linux/ar71xx/files/arch/mips/ar71xx/mach-wpe72.c (revision 0)
@@ -0,0 +1,97 @@
+/*
+ * Compex WPE72 board support
+ *
+ * Copyright (C) 2012 Johnathan Boycejon.bo...@globalreach.eu.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.
+ */
+
+#includeasm/mach-ar71xx/ar71xx.h
+
+#include machtype.h
+#include devices.h
+#include dev-m25p80.h
+#include dev-pb42-pci.h
+#include dev-gpio-buttons.h
+#include dev-leds-gpio.h
+#include dev-usb.h
+
+#define WPE72_GPIO_RESET 12
+#define WPE72_GPIO_LED_DIAG13
+#define WPE72_GPIO_LED_1 14
+#define WPE72_GPIO_LED_2 15
+#define WPE72_GPIO_LED_3 16
+#define WPE72_GPIO_LED_4 17
+
+#define WPE72_KEYS_POLL_INTERVAL 20 /* msecs */
+#define WPE72_KEYS_DEBOUNCE_INTERVAL (3 * WPE72_KEYS_POLL_INTERVAL)
+
+static struct gpio_led wpe72_leds_gpio[] __initdata = {
+ {
+ .name = wpe72:green:led1,
+ .gpio = WPE72_GPIO_LED_1,
+ .active_low = 1,
+ }, {
+ .name = wpe72:green:led2,
+ .gpio = WPE72_GPIO_LED_2,
+ .active_low = 1,
+ }, {
+ .name = wpe72:green:led3,
+ .gpio = WPE72_GPIO_LED_3,
+ .active_low = 1,
+ }, {
+ .name = wpe72:green:led4,
+ .gpio = WPE72_GPIO_LED_4,
+ .active_low = 1,
+ }, {
+ .name = wpe72:green:diag,
+ .gpio = WPE72_GPIO_LED_DIAG,
+ .active_low = 1,
+ }
+};
+
+static struct gpio_keys_button wpe72_gpio_keys[] __initdata = {
+ {
+ .desc = reset,
+ .type = EV_KEY,
+ .code = KEY_RESTART,
+ .debounce_interval = WPE72_KEYS_DEBOUNCE_INTERVAL,
+ .gpio = WPE72_GPIO_RESET,
+ }
+};
+
+static const char *wpe72_part_probes[] = {
+ MyLoader,
+ NULL,
+};
+
+static struct flash_platform_data wpe72_flash_data = {
+ .part_probes= wpe72_part_probes,
+};
+
+static void __init wpe72_setup(void)
+{
+ ar71xx_add_device_m25p80(wpe72_flash_data);
+ ar71xx_add_device_mdio(0, 0x0);
+
+ ar71xx_init_mac(ar71xx_eth0_data.mac_addr, ar71xx_mac_base, 0);
+ ar71xx_init_mac(ar71xx_eth1_data.mac_addr, ar71xx_mac_base, 1);
+
+ ar71xx_add_device_eth(0);
+ ar71xx_add_device_eth(1);
+
+ ar71xx_add_device_usb();
+
+ pb42_pci_init();
+
+ ar71xx_add_device_leds_gpio(-1, ARRAY_SIZE(wpe72_leds_gpio),
+ wpe72_leds_gpio);
+
+ ar71xx_register_gpio_keys_polled(-1, WPE72_KEYS_POLL_INTERVAL,
+ ARRAY_SIZE(wpe72_gpio_keys),
+ wpe72_gpio_keys);
+}
+
+MIPS_MACHINE(AR71XX_MACH_WPE72, WPE72, Compex WPE72, wpe72_setup);
Index: target/linux/ar71xx/files/arch/mips/ar71xx/Makefile
===
--- target/linux/ar71xx/files/arch/mips/ar71xx/Makefile (revision 29830)
+++ target/linux/ar71xx/files/arch/mips/ar71xx/Makefile (working copy)
@@ -71,6 +71,7 @@
obj-$(CONFIG_AR71XX_MACH_WNDR3700) += mach-wndr3700.o
obj-$(CONFIG_AR71XX_MACH_WNR2000) += mach-wnr2000.o
obj-$(CONFIG_AR71XX_MACH_WP543)+= mach-wp543.o
+obj-$(CONFIG_AR71XX_MACH_WPE72)+= mach-wpe72.o
obj-$(CONFIG_AR71XX_MACH_WRT160NL) += mach-wrt160nl.o
obj-$(CONFIG_AR71XX_MACH_WRT400N) += mach-wrt400n.o
obj-$(CONFIG_AR71XX_MACH_WZR_HP_G300NH)+= mach-wzr-hp-g300nh.o
Index: target/linux/ar71xx/files/arch/mips/ar71xx/machtype.h
===
--- target/linux/ar71xx/files/arch/mips/ar71xx/machtype.h (revision 29830)
+++ target/linux/ar71xx/files/arch/mips/ar71xx/machtype.h (working copy)
@@ -79,6 +79,7 @@
AR71XX_MACH_WNDR3700, /* NETGEAR WNDR3700/WNDR3800/WNDRMAC */
AR71XX_MACH_WNR2000,/* NETGEAR WNR2000 */
AR71XX_MACH_WP543, /* Compex WP543 */
+ AR71XX_MACH_WPE72, /* Compex WPE72 */
AR71XX_MACH_WRT160NL, /* Linksys WRT160NL */
AR71XX_MACH_WRT400N,/* Linksys WRT400N */
AR71XX_MACH_WZR_HP_AG300H, /* Buffalo WZR-HP-AG300H */
Index:
Re: [OpenWrt-Devel] Buffalo WZR-HP-G450H support question
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. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Buffalo WZR-HP-G450H support question
On 2012-01-25 11:19 AM, 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. - Felix I have a few of these devices, other than the wireless power, they seem to work really well. As a vpn endpoint for small remote offices, they work great with openwrt on them. Let me know if I can help with testing, etc. -Greg signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] DSL support and luci integration
On Thu, Jan 19, 2012 at 8:51 PM, lee.es...@nowonline.co.uk wrote:
Hi,
I've been using trunk on a Buffalo WBMR-HP-G300H ADSL router with great
success, so I've been looking at the existing DSL support and am keen to
help out getting it better integrated.
Could you explain or point me in the direction of documentation about
how you installed openwrt onto the WBMR-HP-G300H? I just got one to do
some testing with and have loaded dd-wrt, I have serial console
working and I think I can simply write the appropriate image to one of
the mtd devices but if you can detail how you did it it would be
helpful, and reduce the chances of me bricking the device.
The openwrt wiki has hardly any documentation about the WBMR-HP-G300H,
I will try to contribute some info...
Thanks
Andy
I'm conscious that there are likely to be a number of different DSL devices
needing support and have been thinking about a way to have relatively
standard support in LuCI but with flexibility in implementation.
I have put together some patches to start doing this, but thought it best to
check the concepts before getting too far ... also I don't know if anyone
else is working on this or if other ideas have been discussed.
So basically:
A single control script that is shipped as part of the relevant driver (or
app) for the device. For me, this is the lantiq one.
The control script (my suggestion is: /etc/init.d/dsl_control) would be
responsible for the normal start and stop as any rc script would be.
But also ... the control script can be used to get the DSL status, either in
human readable form, or in a standard form parsable by Luci.
In this way any DSL implementation need only provide basic start, stop and
status information and then it could easily appear in LuCI to provide line
status, speed and noise information without any hardware specific detail in
LuCI.
Just by way of example:
root@OpenWrt:~# /etc/init.d/dsl_control status
Line State: UP [0x801: showtime_tc_sync]
Data Rate: 4.064 Mb/s / 448 Kb/s
Line Attenuation: 49.0dB / 26.5dB
Noise Margin: 12.2dB / 25.0dB
Or, the LuCI compatible version ... I went for a loadstring approach that
returned a lua table:
root@OpenWrt:~# /etc/init.d/dsl_control luastat
local dsl={}
dsl.line_state_num=0x801
dsl.line_state_detail=showtime_tc_sync
dsl.line_state=UP
dsl.data_rate_down=4064000
dsl.data_rate_up=448000
dsl.data_rate_down_s=4.064 Mb
dsl.data_rate_up_s=448 Kb
dsl.line_attenuation_down=49.0
dsl.line_attenuation_up=26.5
dsl.noise_margin_down=12.3
dsl.noise_margin_up=25.0
return dsl
I've also implemented the basic summary in the LuCI admin overview page
which looks pretty nice, updates regularly (you can see the noise margin
changing) and doesn't seem to place much load on the system.
There's a bit more to do, it currently doesn't actually check the daemon is
running etc, also I think a start_available and stop_available variable
might be a nice way to control whether LuCI should allow start and stop
buttons ... possible on the network admin page?
Anyway ... just a few ideas, interested in thoughts, I can post the current
patches if there's interest, or happy to explore other ideas if I'm way off
the mark.
Cheers,
Lee.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] DSL support and luci integration
Hi Andy,
I posted a brief summary on the openwrt 'General' forum earlier today ... it's
brief but will hopefully help. I've done 2 now, only bricked one (by
experimenting) and the serial cable makes it pretty easy to recover.
Cheers,
Lee.
On 25 Jan 2012, at 22:01, Andrew Lyon andrew.l...@gmail.com wrote:
On Thu, Jan 19, 2012 at 8:51 PM, lee.es...@nowonline.co.uk wrote:
Hi,
I've been using trunk on a Buffalo WBMR-HP-G300H ADSL router with great
success, so I've been looking at the existing DSL support and am keen to
help out getting it better integrated.
Could you explain or point me in the direction of documentation about
how you installed openwrt onto the WBMR-HP-G300H? I just got one to do
some testing with and have loaded dd-wrt, I have serial console
working and I think I can simply write the appropriate image to one of
the mtd devices but if you can detail how you did it it would be
helpful, and reduce the chances of me bricking the device.
The openwrt wiki has hardly any documentation about the WBMR-HP-G300H,
I will try to contribute some info...
Thanks
Andy
I'm conscious that there are likely to be a number of different DSL devices
needing support and have been thinking about a way to have relatively
standard support in LuCI but with flexibility in implementation.
I have put together some patches to start doing this, but thought it best to
check the concepts before getting too far ... also I don't know if anyone
else is working on this or if other ideas have been discussed.
So basically:
A single control script that is shipped as part of the relevant driver (or
app) for the device. For me, this is the lantiq one.
The control script (my suggestion is: /etc/init.d/dsl_control) would be
responsible for the normal start and stop as any rc script would be.
But also ... the control script can be used to get the DSL status, either in
human readable form, or in a standard form parsable by Luci.
In this way any DSL implementation need only provide basic start, stop and
status information and then it could easily appear in LuCI to provide line
status, speed and noise information without any hardware specific detail in
LuCI.
Just by way of example:
root@OpenWrt:~# /etc/init.d/dsl_control status
Line State: UP [0x801: showtime_tc_sync]
Data Rate: 4.064 Mb/s / 448 Kb/s
Line Attenuation: 49.0dB / 26.5dB
Noise Margin: 12.2dB / 25.0dB
Or, the LuCI compatible version ... I went for a loadstring approach that
returned a lua table:
root@OpenWrt:~# /etc/init.d/dsl_control luastat
local dsl={}
dsl.line_state_num=0x801
dsl.line_state_detail=showtime_tc_sync
dsl.line_state=UP
dsl.data_rate_down=4064000
dsl.data_rate_up=448000
dsl.data_rate_down_s=4.064 Mb
dsl.data_rate_up_s=448 Kb
dsl.line_attenuation_down=49.0
dsl.line_attenuation_up=26.5
dsl.noise_margin_down=12.3
dsl.noise_margin_up=25.0
return dsl
I've also implemented the basic summary in the LuCI admin overview page
which looks pretty nice, updates regularly (you can see the noise margin
changing) and doesn't seem to place much load on the system.
There's a bit more to do, it currently doesn't actually check the daemon is
running etc, also I think a start_available and stop_available variable
might be a nice way to control whether LuCI should allow start and stop
buttons ... possible on the network admin page?
Anyway ... just a few ideas, interested in thoughts, I can post the current
patches if there's interest, or happy to explore other ideas if I'm way off
the mark.
Cheers,
Lee.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] x86 sysupgrade
On 1/25/12 7:58 AM, Martin Roecker wrote: Hi, On 23.01.2012 07:28, Philip Prindeville wrote: For those of us using x86-based platforms we'd like to have a way to do in-place upgrades without losing configuration state. How do you perform your updates at the moment? I ask because the only way to write a new image to my Alix 2D13 ist to use dd. Sysupgrade (with and without keeping configfiles) does not write the image. This seems to be a problem only with the squashfs image. Martin I use dd, and it blows away all of my configuration state... ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Let's fix the OpenWrt patch acceptance problem!
On 1/25/12 5:30 AM, Dave Taht wrote: A second, large problem (in my mind), is that I would like to find a process for getting stuff upstream into the mainline kernel. Returning to handling the patch backlog: One way to perhaps help this is for the overall schedule to be more widely publicised and to work on more of a time based manner. In my case I've been trying to adhere to the kernel release schedule + .1 + X, where .1 is the first followup to the 'stable' kernel release, where X is the delta that it seems to take between a release and patches appearing. 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. Ironically, my patches are being held back because they're not sufficiently 'vetted', but the reason they aren't vetted is because I can't even get a box to boot with other people's insufficiently vetted ath-common changes! So my lack of vetting is the symptom, but not the cause. I'll be happy to boot 3.2 if and when I can, which is to say when the atheros patches are adequately tested for ath5k. Or we can simply state that the ath5k isn't supported hardware in OpenWRT, and I'll throw them in the trash can and move on and order an Ath9k card from Amazon. Which is it to be? -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Let's fix the OpenWrt patch acceptance problem!
On 01/25/2012 02:50 PM, Philip Prindeville wrote: 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. Ironically, my patches are being held back because they're not sufficiently 'vetted', but the reason they aren't vetted is because I can't even get a box to boot with other people's insufficiently vetted ath-common changes! Right, this sounds familiar, except it's with e/glibc stuff. No one much has tested it because it's not in SVN, etc. Moreover, it doesn't affect most users, and without them, e/glibc doesn't work at all. I'm more than willing to take responsibility for this stuff. Exactly how that gets done doesn't bother me very much, since every project is different anyway, only that is a defined path for it getting in at some point. By comparison, I've had Mozilla patches languish for several *years*. Other than that, I'm going a great deal of work testing/using ar71xx, although it's small stuff all over the place. Some of this certainly isn't suitable for mainstream code (much of it I've posted as patches anyway), but I think it likely people would be interested anyway. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt-Users] Serious business hardware
On 23/01/12 04:34 AM, Russell Senior wrote: Weedy == Weedy weedy2...@gmail.com writes: Requirements: - 500mhz or more - 128mb ram+, DDR+ - 32mb flash - 2 gigabit ports (but I would like 4) - 1 minipci, bonus points for more - cf/sd card slot - available enclosure that isn't more then 75% the cost of the board Weedy Thank you. I check them and ruled them out already. Howabout a RouterStation Pro? They seem to hit all your criteria except the flash (only 16M on board). If you have large piles of cash, you could look at the Soekris net6501. In case anyone is following. http://www.balticnetworks.com/mikrotik-routerboard-rb-433g.html This is about the closest your going to get to the rsPro, this company only has like 2 left because they were modding them in-house. MikroTik has noticed the demand for this and are supposed to start production of the same thing very soon. Once I get mine I'll start trying to get openwrt on it, last I looked the switch driver needs to be forward ported or something. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Let's fix the OpenWrt patch acceptance problem!
On 1/25/12 4:07 PM, Peter Naulls wrote: Right, this sounds familiar, except it's with e/glibc stuff. No one much has tested it because it's not in SVN, etc. Moreover, it doesn't affect most users, and without them, e/glibc doesn't work at all. I build with eglibc because I need the g729 codecs for Asterisk, and they only come in binary. I'm more than willing to take responsibility for this stuff. Exactly how that gets done doesn't bother me very much, since every project is different anyway, only that is a defined path for it getting in at some point. By comparison, I've had Mozilla patches languish for several *years*. Didn't realize there were any other Mozilla hackers here... I did the QoS patches for FF and TB. -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: Rework ramips_eth to not require irqsave locking anymore
On Wed, Jan 25, 2012 at 6:08 PM, Roman Yeryomin leroi.li...@gmail.com wrote: On 23 January 2012 16:26, Helmut Schaa helmut.sc...@googlemail.com wrote: Well, ok, I'll retest everything again (a bit later) and let you know the results. Ok, thanks. It could be that you were right that my testing environment/hardware is not good enough. When I started to use iperf wireless card (well, probably the driver) in my laptop behaved very bad. It hanged pretty frequently (~20% of the time) and speed tests were very weird - sometimes I was getting stable 65 Mbit/s but sometimes it was jumping from 20 to 65 per test. Device placement and environment was the same all the time. The thing is that I have to use proprietary broadcom driver for this card (BCM4321) to get n mode. And it's very unstable. So, for now, I can't say anything useful. Probably I should get some good and supported 802.11n hardware. Any advises for miniPCI and/or miniPCI express cards? Atheros based? Ralink? I usually use Intel devices (5100 or 5300) as clients for my tests. However, be aware that wifi tests are never really accurate due to the nature of the wireless media. And also the rate control interaction with rt2x00 is not yet perfect, this might be why you sometimes see these big throughput differences. I've got a few more patches to improve that but they are not ready for upstream proposal yet. Thanks for testing again! Helmut ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
