Re: [OpenWrt-Devel] [PATCH] ramips: add support for device D-link DIR620 revA1
Hi! The patch is mangled by your MUA. I see some strange symbols. Also I think that your indentation style is not quite readable. В Wed, 18 Jul 2012 17:37:13 +0700 Сергей Василюгин пишет: > Signed-off-by: Serge Vasilugin > > Index: target/linux/ramips/files/arch/mips/ralink/rt305x/Kconfig > === > --- target/linux/ramips/files/arch/mips/ralink/rt305x/Kconfig (revision 32760) > +++ target/linux/ramips/files/arch/mips/ralink/rt305x/Kconfig (working copy) > @@ -159,6 +159,11 @@ > select RALINK_DEV_GPIO_BUTTONS > select RALINK_DEV_GPIO_LEDS > > +config RT305X_MACH_DIR_620_REVA > + bool "D-Link DIR-620 revA board support" > + select RALINK_DEV_GPIO_BUTTONS > + select RALINK_DEV_GPIO_LEDS > + IMO this should be spaced the same way as other boards. This helps reading. > endmenu > > endif > Index: target/linux/ramips/files/arch/mips/ralink/rt305x/mach-dir-620-reva.c > === > --- target/linux/ramips/files/arch/mips/ralink/rt305x/mach-dir-620-reva.c > (revision 0) > +++ target/linux/ramips/files/arch/mips/ralink/rt305x/mach-dir-620-reva.c > (revision 0) > @@ -0,0 +1,104 @@ > +/* > + * D-Link DIR-620 rev A board support > + * > + * Copyright (C) 2009-2010 Gabor Juhos > + * Copyright (C) 2012 Sergey Vasiliugin > + * > + * 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 > +#include > + > +#include > +#include > +#include > +#include > +#include > + > +#include "devices.h" > + > +#define DIR_620A_GPIO_LED_STATUS_AMBER 8 > +#define DIR_620A_GPIO_LED_STATUS_GREEN 9 > +#define DIR_620A_GPIO_LED_WPS_BLUE 11 > +#define DIR_620A_GPIO_LED_WPS_GREEN 13 Hm, I think, this led (gpio 13) is amber in my dir-620. I'll check the revision... [snip] -- Alexander ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH/RFC v1] add kernel-accelerated PPtP support
Hi Daniel, В Tue, 15 May 2012 14:55:20 +0300 Daniel Golle пишет: > On 14/05/12 02:35, Daniel Golle wrote: > > On Sat, May 05, 2012 at 08:23:06PM +0200, Felix Fietkau wrote: > >> Any package that adds a protocol handler script now needs to have netifd > >> support (netifd will be enabled by default soon, once the remaining > >> scripts have been ported). > >> Today I finished porting over the existing pptp script. The netifd > >> version is quite simple, you can use it as template. > > I used the netifd'd pptp.sh script and integrated it into ppp.sh. > > To remain compatible, I also added support for ppp-mod-pptp to files.old. > > Besides this, everything as it was. > > I'll test it extensively on ar71xx and kirkwood in the next days. > With some small corrections in options.pptp (which should probably be retired > in > favour of having stuff configurable through UCI anyway) I got stable and > well-performing results when using the pptp plugin and kernel-mode pptp > instead > of user-space pptpd. > I even overdid it and chained several L2TPv2 and PPTP connections within each > other until the resulting MTU of the inner-most tunnel ended up ridiculously > low > -- it's all working great for more than 18 hours now on a small Atheros > AR7240. > > Considerung the footprint, a single quite busy PPtP session looks like this on > that box: > PID PPID USER STAT VSZ %VSZ %CPU COMMAND > 12267 1 root S 1644 6% 0% /usr/sbin/pppd plugin pptp.so > pptp_se > 12270 1 root S 1644 6% 0% /usr/sbin/pppd plugin pptp.so > pptp_se > > uptime: 11:53:50 up 18:29, load average: 0.21, 0.24, 0.19 > loadavg: 0.29 0.26 0.20 1/48 12601 > > So obviously, obviously the call-manager is still fork'ed into a seperate > process which is created and being controllled by the plugin. > > Besides that I tested it on rt305x(mipsel), kirkwood(armel) and x86. > > After integrating #31724 this also starts up correctly and one-by-one after a > reboot, not needing manual ifup/ifdown calls any more if initially > unresolvable > hostnames instead of plain IP addresses are used. > > Please advise me what is still missing or needs to be changed. > How is everybody's schedule regarding the integration and changing of > procotols > to netifd. The question is basically, if I should work towards getting this > integrated asap or if we want to get stuff entirely polished and working in > netifd with the existing pptp implementation and then eventually switch over > to > kernel-mode pptp. Thank you very much for the great work! Do you have a git repository somewhere with all this stuff you mentioned applied (patches, bug fixes, options?) so I can test it? -- Alexander ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Driver(s) for Synopsys' DesignWare USB OTG
В Fri, 20 Jan 2012 17:03:01 +0400 Nikolai Zhubr пишет: > Hello Alexander, > > 20.01.2012 13:01, Alexander Gordeev: > [trim] > > > > IMO a separate repository (or adoption into staging) would be better > > because there are too many interested parties and also the main dwc-otg > > development happens not in openwrt. > > > > Where does it happen? > > I've actually got a feeling that in fact no real development is now > happening, but rather some manufacturers and interested users make their > copies (of basically the same thing), reformat tabs and whitespace all > over 200k lines of code as they feel cool, then in some cases introduce > several random 3-line additions/fixes in order to make their specific > device just do what they need at the moment... and finally (sometimes) > publish this as "new shining" version. Now this is NOT a development, > IMHO. I'd be happy if you prove me wrong however. You are right, no need to argue. :) However, there were at least several attempts to push dwc-otg to mainline through linuxppc-dev list. This is what I meant. > The only excuse I'd see for creating yet another repository is if it > appears too hard (or too long) to get stuff accepted to openwrt (AFAICS > openwrt maintainers are somewhat overburdened already, but no idea how > much really) I think the real goal is to have this driver in the mainline kernel and then it will be in openwrt automatically. Ok, it would be cool to merge at least those several implementations inside openwrt (octeon, ramips, etc). But there are others too so I think this attempt should not be bound to Openwrt or any other project or we will always find different drivers all other the net. -- Alexander ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Driver(s) for Synopsys' DesignWare USB OTG
Hi Nikolai, В Thu, 19 Jan 2012 22:39:54 +0400 Nikolai Zhubr пишет: > Hello Conor, > > I'm now trying ver 2.72 basically from openwrt trunk with some tiny > amlogic-specific additions. I think 2.72 is most relevant currently (and > nothing newer exists apparently) but device-mode does not work well for > me yet. And 2.60 was no better for me in this respect. Can't test > host-mode at the moment because it is quite difficult to arrange as long > as USB is the only wired interface physycally available and wifi not > working yet (It's a tablet, ARMv7-based) > > If I manage to get it to work satisfactory at least in device-mode, I'll > certainly share my findings and either try to submit patches to openwrt > (I'd prefer that way) or maybe create a separate repository somewhere > (downside in this case would be yet more scattering of this driver, > which I'd like to avoid). If all goes well then I'll probably test > host-mode a bit later (Not sure when it happens exactly) > > Anyway, it would be nice to eventually combine all those various > versions floating around (targeted for different architectures and > revisions of controller) into a single unified version. > > So I suppose you'll be able to do some testing in host-mode on your > platform, if it happens to be necessary? IMO a separate repository (or adoption into staging) would be better because there are too many interested parties and also the main dwc-otg development happens not in openwrt. -- Alexander ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RT3052F] Supporting Sitecom WL-341 (rebadged Sercomm IP1006RRv2 with half ram & flash)
В Thu, 19 Jan 2012 09:55:23 +0100 Helmut Schaa пишет: > On Thu, Jan 19, 2012 at 2:33 AM, Marco Antonio Mauro > wrote: > > 2. The device boots successfully but I cannot enable the wifi access > > point. In the system log there is an error. You can see the log here: > > http://wiki.openwrt.org/toh/sitecom/wl-341#notes > > I personally think it's a not enough RAM problem, but the device tells > > me there is over 5MB of ram available at boot time so I'm a bit > > puzzled. > > Indeed the driver is not able to allocate the queue entries it requires :( > > I only used rt2x00 on a 32MByte RT3052 SoC yet, so not sure how to > debug that further on your 16MByte machine ... I have a rt3050 board with 16MBs of RAM and had to add this to rc.local: for i in $(seq 1 10); do [ -h /sys/class/net/br-lan/brif/wlan0 ] && break sleep 3 wifi up done It usually starts after 2-3 iterations. Hope it will be more memory-efficient some time... -- Alexander ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/3] packages/utils/usb-modeswitch: use the hammer
Hi Daniel, Sorry for the delay. В Wed, 2 Nov 2011 19:42:12 +0100 Daniel Golle пишет: > Hi Alexander, > > > On 11/02/2011 01:54 PM, Alexander Gordeev wrote: > > Please remove usb-storage module from your filesystem. You can then > > restore it from /rom. This will show us if the problem is with > > usb-storage. > > Removed usb-storage from rootfs, and usb-modeswitch is still failing on the > first try and succeeding later on: > > http://pastebin.com/mdAH2s8N > > http://pastebin.com/ht2bPF8j > > http://pastebin.com/yUirS7pc > > > it seems that usb-modeswitch for some reason doesn't always check if the old > usb-product-id has disappeared. any idea why it doesn't just retry sending the > message until the old device is gone for good and/or a wanted-product-id shows > up instead? Sometimes I think that usb_modeswitch's design is not very good too but it is already working great for lots of devices. I think you should trace usb_modeswitch at this point and try to understand why it doesn't do the job. It also may help to usbsnoop the switching sequence under Windows and check if there is a difference. Does it also work on other other computers and routers? Probably we should move to usb_modeswitch forum (I think they don't have a mail list) to get help from its author if we can't fix it ourselves. -- Alexander ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/3] packages/utils/usb-modeswitch: use the hammer
Hi Daniel, В Mon, 31 Oct 2011 15:43:17 +0100 Daniel Golle пишет: > Hi Alexander, > > On 10/26/2011 06:00 PM, Alexander Gordeev wrote: > > I think this is not necessarily USB problem. I've got a couple of times > > in the same situation when libusb returned something strange. Both > > times it was a bug in uClibc. :) > > I'll be happy to help with this issue. > So now, I got another o2 prepaid surfstick and changed the hotplug script so > it > calls strace $usb_modeswitch, > see > modeswitch fails (1st try) http://pastebin.com/a0V4KC3D > vs. > modeswitch succeeds (2nd try) http://pastebin.com/nbC0Ndfi > > the first significant difference between the two logs seems to be that on the > first try, usb-storage didn't claim the endpoint yet. After claiming the This is the first try (which failed) and I think that it is exactly the opposite i.e. usb-storage has already claimed the device and usb-modeswitch detaches it: ioctl(3, USBDEVFS_GETDRIVER, 0x7f8ce808) = 0 ioctl(3, USBDEVFS_IOCTL, 0x7f8ce900)= 0 ioctl(3, USBDEVFS_CLAIMINTERFACE, 0x7f8ce904) = 0 And the second try (that worked), ENODATA is returned when either no interface with this number is present or no driver is active, which is the case here probably: ioctl(3, USBDEVFS_GETDRIVER, 0x7f909378) = -1 ENODATA (No data available) ioctl(3, USBDEVFS_CLAIMINTERFACE, 0x7f909474) = 0 > interface with libusb, some calls to USBDEVFS_SUBMITURB go out, interestingly > 2 > times in the first case (fails) and 3 times in the 2nd case (succeeds)... > Then there seems to be some active waiting for the reply in both cases, just > the > on the first try usb_modeswitch gives up waiting after a long time and on the > retry it receives a reply a few moments after the message was sent. Correction: both times three URBs are sent: The first try: 1. send first URB, wait -> success 2. send second URB, wait -> timeout, discard urb 3. send third URB, wait -> timeout, discard urb 4. check that target device appears many times -> no success The second try: 1. send first URB, wait -> success 2. send second URB, wait -> success 3. send third URB, wait -> timeout, discard urb 4. release interface 5. check for target device -> success, it's now /proc/bus/usb/001/003 > My first thought was to try just waiting a bit longer before calling > usb_modeswitch, so a added a sleep 60 in the hotplug script before calling > usb_modeswitch. Now, usb-storage does claim the interface but usb_modeswitch > still fails, eventhough usb-storage was loaded and the boot has fully > completed > at the time usb_modeswitch was called then. See > > modeswitch still fails when sleeping 60 seconds before the 1st try > http://pastebin.com/0uQVWDx1 Right, I see that it deactivates usb-storage here. So the rule I see here is that: 1. if usb-modeswitch has to deactivate usb-storage, it fails 2. if usb-modeswitch doesn't have to deactivate usb-storage, it works > Any ideas? Please remove usb-storage module from your filesystem. You can then restore it from /rom. This will show us if the problem is with usb-storage. -- Alexander ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/3] packages/utils/usb-modeswitch: use the hammer
В Wed, 26 Oct 2011 17:48:50 +0200 Daniel Golle пишет: > On 10/26/2011 05:24 PM, Alexander Gordeev wrote: > > В Tue, 25 Oct 2011 14:04:18 +0200 > > Daniel Golle пишет: > >> Unfortunately I returned the collection of 3G-dongles to where it came from > >> after I got all of them working... > >> However, it seems to be more of a libusb problem than directly related to > >> usb_modeswitch. > > This is very bad IMO. This workaround just hides the real problem and > > you are not going to fix it (cause you don't have the hardware anymore) > > so it's going to stay for a long time. > I get your point and ordered another ZDE 3g-modem to further investigate the > issue, it'll arrive in a couple of days. Unfortunately I don't have equipment > capable of analyzing the actual USB 2.0 traffic. Yet, I could try with a > couple > different USB hosts (ar7420, NEC PCI EHCI connected to the pci-bus of on > ar2315, > x86) and attack usb_modeswitch with gdb, strace and such, probably enable more > kernel-debug options, ... > I'll find some more time for that during the weekend and be glad for every > type > of support with that as soon as I got the ZDE dongle. > So if you or anyone wants to get your hands on that box, email me your SSH > pubkey and I'll add it and make dropbear listen on IPv6. I think this is not necessarily USB problem. I've got a couple of times in the same situation when libusb returned something strange. Both times it was a bug in uClibc. :) I'll be happy to help with this issue. -- Alexander ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/3] packages/utils/usb-modeswitch: use the hammer
В Tue, 25 Oct 2011 14:04:18 +0200 Daniel Golle пишет: > On 10/25/2011 01:30 PM, Alexander Gordeev wrote: > > Can you please send the log of usb_modeswitch and dmesg when the > > problem occurs? > > Probably it can be fixed easier and much more reliable in the > > usb_modeswitch code. Also other platforms will benefit from it. > Unfortunately I returned the collection of 3G-dongles to where it came from > after I got all of them working... > However, it seems to be more of a libusb problem than directly related to > usb_modeswitch. > Most of the time, I get > Response reading got error -145 > at the first time running usb_modeswitch. Occasonally, it also complained > about > Device is gone, skipping any further commands > after trying to send the message and then quits with exit(0) though the device > didn't actually perform any switching. > > When calling usb_modeswitch manually it seems to work every time, also when > hotplugging the device everything goes well. The problem only occurs when the > device is already plugged in during a cold boot (I already made sure > /proc/bus/usb is mounted before usb_modeswitch gets called). > > Depending on the 3G-dongle used, usb_modeswitch finally succeeds on the 3rd, > 4th > or 5th time being called by the hotplug script... > > Possible reasons may be: > - high system load during boot makes a USB-related race-condition go wrong > (dwc_otg on Ralink Rt3052F in my case, so that's not that unlikely) > - USB-Dongle didn't finish booting it's firmware but already offers the > storage EPs. > > However, besides usb_modeswitch there is no USB-related problem, I tried > connecting a crapy USB-hub to the single USB-port of the Rt3052, connect to > the > internet through 3G and simultanously share a pendrive with samba and all > works > well even under high load. This is very bad IMO. This workaround just hides the real problem and you are not going to fix it (cause you don't have the hardware anymore) so it's going to stay for a long time. -- Alexander ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/3] packages/utils/usb-modeswitch: use the hammer
В Mon, 24 Oct 2011 16:10:14 +0200
Daniel Golle пишет:
> Not particularly beautiful but doing the trick...
>
> Signed-off-by: Daniel Golle
>
> diff --git a/utils/usb-modeswitch/files/modeswitch.hotplug
> b/utils/usb-modeswitch/files/modeswitch.hotplug
> index 1aecb1f..7f9ce94 100644
> --- a/utils/usb-modeswitch/files/modeswitch.hotplug
> +++ b/utils/usb-modeswitch/files/modeswitch.hotplug
> @@ -120,7 +120,20 @@ if [ "$ACTION" = add ]; then
> # If a candidate is remaining, start usb-modeswitch
> [ -n "$configs" ] && {
> log "$DEVICENAME: Selecting ${configs%% *} for mode
> switching"
> - $modeswitch -c "${configs%% *}"
> + # ugly workaround, but working for all hw we got for
> testing
> + switching_done=0
> + switching_tries=0
> + local usb_dir="/sys/$DEVPATH"
> + [ -f "$usb_dir/idVendor" ] || usb_dir="${usb_dir%/*}"
> + while [ $switching_done -lt 1 -a $switching_tries -le 6
> ]; do
> + $modeswitch -I -D -n -s 30 -c "${configs%% *}"
> + if [ $(sanitize "$usb_dir/idProduct") -eq $uPid
> ]; then
> + log "switching seemingly failed"
> + else
> + switching_done=1
> + fi
> + switching_tries=$(( $switching_tries + 1 ))
> + done
> }
> }
> fi
Can you please send the log of usb_modeswitch and dmesg when the
problem occurs?
Probably it can be fixed easier and much more reliable in the
usb_modeswitch code. Also other platforms will benefit from it.
--
Alexander
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCHv3 1/2] ramips: combine led setup for all boards in one file
This removes unnecessary duplication and simplifies led setup for new
boards. It would be a one line change most likely.
Signed-off-by: Alexander Gordeev
---
.../ramips/base-files/etc/uci-defaults/fonera20n | 24 --
.../ramips/base-files/etc/uci-defaults/hw550-3g| 24 --
.../linux/ramips/base-files/etc/uci-defaults/leds | 34
.../base-files/etc/uci-defaults/mofi3500-3gn | 24 --
.../linux/ramips/base-files/etc/uci-defaults/nw718 | 13 ---
5 files changed, 34 insertions(+), 85 deletions(-)
delete mode 100755 target/linux/ramips/base-files/etc/uci-defaults/fonera20n
delete mode 100755 target/linux/ramips/base-files/etc/uci-defaults/hw550-3g
create mode 100755 target/linux/ramips/base-files/etc/uci-defaults/leds
delete mode 100755 target/linux/ramips/base-files/etc/uci-defaults/mofi3500-3gn
diff --git a/target/linux/ramips/base-files/etc/uci-defaults/fonera20n
b/target/linux/ramips/base-files/etc/uci-defaults/fonera20n
deleted file mode 100755
index 006f805..000
--- a/target/linux/ramips/base-files/etc/uci-defaults/fonera20n
+++ /dev/null
@@ -1,24 +0,0 @@
-#!/bin/sh
-#
-# Copyright (C) 2011 OpenWrt.org
-#
-
-fonera20n_set_leds() {
- uci batch <https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCHv3 2/2] ramips: combine network setup for all boards in one file
Inspired by the patch from Roman Yeryomin. Thanks, Roman!
This removes unnecessary duplication and simplifies network setup for new
boards. It would be a one line change most likely.
Signed-off-by: Alexander Gordeev
---
.../ramips/base-files/etc/uci-defaults/network | 117 +++-
.../linux/ramips/base-files/etc/uci-defaults/nw718 | 36 --
2 files changed, 114 insertions(+), 39 deletions(-)
delete mode 100755 target/linux/ramips/base-files/etc/uci-defaults/nw718
diff --git a/target/linux/ramips/base-files/etc/uci-defaults/network
b/target/linux/ramips/base-files/etc/uci-defaults/network
index 35b2fcc..6601621 100755
--- a/target/linux/ramips/base-files/etc/uci-defaults/network
+++ b/target/linux/ramips/base-files/etc/uci-defaults/network
@@ -1,6 +1,15 @@
#!/bin/sh
-RT3X5X=`cat /proc/cpuinfo | grep RT3.5`
-[ -z "${RT3X5X}" ] || {
+
+. /etc/functions.sh
+. /lib/ramips.sh
+
+if [ ! -x /usr/sbin/maccalc ]; then
+ echo "$0: maccalc not found!"
+ return
+fi
+
+create_lan_wan()
+{
uci batch <&2
+ return
+ fi
+
+ dd bs=1 skip=$seek count=6 if=$part 2>/dev/null | /usr/sbin/maccalc
bin2mac
+}
+
+get_mac_nvram()
+{
+ local mtdname="$1"
+ local key="$2"
+ local part
+ local mac_dirty
+
+ part=$(find_mtd_part "$mtdname")
+ if [ -z "$part" ]; then
+ echo "get_mac_nvram: partition $mtdname not found!" >&2
+ return
+ fi
+
+ mac_dirty=$(strings "$part" | sed -n 's/'"$key"'=//p')
+ # "canonicalize" mac
+ maccalc add "$mac_dirty" 0
+}
+
+set_macs()
+{
+ local lan_mac="$1"
+ local wan_mac="$2"
+
+ echo "Setting LAN mac address to: $lan_mac" >&2
+ echo "Setting WAN mac address to: $wan_mac" >&2
+
+ uci batch <&2
+ return
+ fi
+
+ set_macs_only_lan "$lan_mac"
+}
+
+set_macs_only_lan_from_nvram()
+{
+ local mtdname="$1"
+ local key="$2"
+ local lan_mac
+
+ lan_mac=$(get_mac_nvram "$mtdname" "$key")
+ if [ -z $lan_mac ]; then
+ echo "set_macs_only_lan_from_nvram: can't extract mac address
from $part" >&2
+ return
+ fi
+
+ set_macs_only_lan "$lan_mac"
+}
+
+board=$(ramips_board_name)
+
+case $board in
+ f5d8235-v2)
+ create_lan_wan
+ set_macs_only_lan_from_mtd "u-boot" 262148
+ ;;
+ argus-atp52b | \
+ nw718)
+ create_lan_wan
+ set_macs_only_lan_from_mtd "factory" 4
+ ;;
+ *)
+ echo "network: no network setup for this board defined" >&2
+esac
diff --git a/target/linux/ramips/base-files/etc/uci-defaults/nw718
b/target/linux/ramips/base-files/etc/uci-defaults/nw718
deleted file mode 100755
index 6fd96df..000
--- a/target/linux/ramips/base-files/etc/uci-defaults/nw718
+++ /dev/null
@@ -1,36 +0,0 @@
-#!/bin/sh
-#
-# Copyright (C) 2011 OpenWrt.org
-#
-
-nw718_set_macs() {
- local part
- local lan_mac
- local wan_mac
-
- [ -z $(which maccalc) ] && return
-
- . /etc/functions.sh
-
- part=$(find_mtd_part "factory")
- [ -z $part ] && return
-
- lan_mac=$(dd bs=1 skip=4 count=6 if=$part 2>/dev/null | maccalc bin2mac)
- [ -z $lan_mac ] && return
-
- wan_mac=$(maccalc add $lan_mac 1)
-
- uci batch <https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCHv2 1/2] ramips: combine led setup for all boards in one file
Sorry, just realized that I sent the "led" patch unmodified. So I'll resend it. -- Alexander signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCHv2 1/2] ramips: combine led setup for all boards in one file
This removes unnecessary duplication and simplifies led setup for new
boards. It would be a one line change most likely.
Signed-off-by: Alexander Gordeev
---
.../ramips/base-files/etc/uci-defaults/fonera20n | 24 -
.../ramips/base-files/etc/uci-defaults/hw550-3g| 24 -
.../linux/ramips/base-files/etc/uci-defaults/leds | 36
.../base-files/etc/uci-defaults/mofi3500-3gn | 24 -
.../linux/ramips/base-files/etc/uci-defaults/nw718 | 13 ---
5 files changed, 36 insertions(+), 85 deletions(-)
delete mode 100755 target/linux/ramips/base-files/etc/uci-defaults/fonera20n
delete mode 100755 target/linux/ramips/base-files/etc/uci-defaults/hw550-3g
create mode 100755 target/linux/ramips/base-files/etc/uci-defaults/leds
delete mode 100755 target/linux/ramips/base-files/etc/uci-defaults/mofi3500-3gn
diff --git a/target/linux/ramips/base-files/etc/uci-defaults/fonera20n
b/target/linux/ramips/base-files/etc/uci-defaults/fonera20n
deleted file mode 100755
index 006f805..000
--- a/target/linux/ramips/base-files/etc/uci-defaults/fonera20n
+++ /dev/null
@@ -1,24 +0,0 @@
-#!/bin/sh
-#
-# Copyright (C) 2011 OpenWrt.org
-#
-
-fonera20n_set_leds() {
- uci batch <https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCHv2 2/2] ramips: combine network setup for all boards in one file
Inspired by the patch from Roman Yeryomin. Thanks, Roman!
This removes unnecessary duplication and simplifies network setup for new
boards. It would be a one line change most likely.
Signed-off-by: Alexander Gordeev
---
.../ramips/base-files/etc/uci-defaults/network | 117 +++-
.../linux/ramips/base-files/etc/uci-defaults/nw718 | 36 --
2 files changed, 114 insertions(+), 39 deletions(-)
delete mode 100755 target/linux/ramips/base-files/etc/uci-defaults/nw718
diff --git a/target/linux/ramips/base-files/etc/uci-defaults/network
b/target/linux/ramips/base-files/etc/uci-defaults/network
index 35b2fcc..6601621 100755
--- a/target/linux/ramips/base-files/etc/uci-defaults/network
+++ b/target/linux/ramips/base-files/etc/uci-defaults/network
@@ -1,6 +1,15 @@
#!/bin/sh
-RT3X5X=`cat /proc/cpuinfo | grep RT3.5`
-[ -z "${RT3X5X}" ] || {
+
+. /etc/functions.sh
+. /lib/ramips.sh
+
+if [ ! -x /usr/sbin/maccalc ]; then
+ echo "$0: maccalc not found!"
+ return
+fi
+
+create_lan_wan()
+{
uci batch <&2
+ return
+ fi
+
+ dd bs=1 skip=$seek count=6 if=$part 2>/dev/null | /usr/sbin/maccalc
bin2mac
+}
+
+get_mac_nvram()
+{
+ local mtdname="$1"
+ local key="$2"
+ local part
+ local mac_dirty
+
+ part=$(find_mtd_part "$mtdname")
+ if [ -z "$part" ]; then
+ echo "get_mac_nvram: partition $mtdname not found!" >&2
+ return
+ fi
+
+ mac_dirty=$(strings "$part" | sed -n 's/'"$key"'=//p')
+ # "canonicalize" mac
+ maccalc add "$mac_dirty" 0
+}
+
+set_macs()
+{
+ local lan_mac="$1"
+ local wan_mac="$2"
+
+ echo "Setting LAN mac address to: $lan_mac" >&2
+ echo "Setting WAN mac address to: $wan_mac" >&2
+
+ uci batch <&2
+ return
+ fi
+
+ set_macs_only_lan "$lan_mac"
+}
+
+set_macs_only_lan_from_nvram()
+{
+ local mtdname="$1"
+ local key="$2"
+ local lan_mac
+
+ lan_mac=$(get_mac_nvram "$mtdname" "$key")
+ if [ -z $lan_mac ]; then
+ echo "set_macs_only_lan_from_nvram: can't extract mac address
from $part" >&2
+ return
+ fi
+
+ set_macs_only_lan "$lan_mac"
+}
+
+board=$(ramips_board_name)
+
+case $board in
+ f5d8235-v2)
+ create_lan_wan
+ set_macs_only_lan_from_mtd "u-boot" 262148
+ ;;
+ argus-atp52b | \
+ nw718)
+ create_lan_wan
+ set_macs_only_lan_from_mtd "factory" 4
+ ;;
+ *)
+ echo "network: no network setup for this board defined" >&2
+esac
diff --git a/target/linux/ramips/base-files/etc/uci-defaults/nw718
b/target/linux/ramips/base-files/etc/uci-defaults/nw718
deleted file mode 100755
index 6fd96df..000
--- a/target/linux/ramips/base-files/etc/uci-defaults/nw718
+++ /dev/null
@@ -1,36 +0,0 @@
-#!/bin/sh
-#
-# Copyright (C) 2011 OpenWrt.org
-#
-
-nw718_set_macs() {
- local part
- local lan_mac
- local wan_mac
-
- [ -z $(which maccalc) ] && return
-
- . /etc/functions.sh
-
- part=$(find_mtd_part "factory")
- [ -z $part ] && return
-
- lan_mac=$(dd bs=1 skip=4 count=6 if=$part 2>/dev/null | maccalc bin2mac)
- [ -z $lan_mac ] && return
-
- wan_mac=$(maccalc add $lan_mac 1)
-
- uci batch <https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] ramips: combine network setup for all boards in one file
В Wed, 21 Sep 2011 16:22:24 +0200 Gabor Juhos пишет: > Hi Alexander, > > > Inspired by the patch from Roman Yeryomin. Thanks, Roman! > > This removes unnecessary duplication and simplifies network setup for new > > boards. It would be a one line change most likely. > > > > Signed-off-by: Alexander Gordeev > > The patch does not apply against trunk. It seems that you have some other > changes in your tree. Right, I have other changes. I'll test both patches against trunk and resend. Thank you! -- Alexander signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] ramips: combine led setup for all boards in one file
В Wed, 21 Sep 2011 16:01:04 +0200
Gabor Juhos пишет:
> 2011.09.18. 23:18 keltezéssel, Alexander Gordeev írta:
> > This removes unnecessary duplication and simplifies led setup for new
> > boards. It would be a one line change most likely.
> >
> > Signed-off-by: Alexander Gordeev
> > ---
>
> <...>
>
> > -fi
> > diff --git a/target/linux/ramips/base-files/etc/uci-defaults/leds
> > b/target/linux/ramips/base-files/etc/uci-defaults/leds
> > new file mode 100755
> > index 000..e814d1e
> > --- /dev/null
> > +++ b/target/linux/ramips/base-files/etc/uci-defaults/leds
> > @@ -0,0 +1,36 @@
> > +#!/bin/sh
> > +
> > +. /lib/ramips.sh
> > +
> > +set_usb_led() {
> > + local sysfs="$1"
> > +
> > + uci batch < > +set system.usb_led=led
> > +set system.usb_led.name='usb'
> > +set system.usb_led.sysfs='$sysfs'
> > +set system.usb_led.trigger='usbdev'
> > +set system.usb_led.dev='1-1'
> > +set system.usb_led.interval='50'
> > +commit system
> > +EOF
> > +}
> > +
> > +board=$(ramips_board_name)
> > +
> > +case $board in
> > + fonera20n)
> > + set_usb_led "fonera20n:amber:usb"
> > + ;;
> > + hw550-3g)
> > + set_usb_led "hw550-3g:green:usb"
> > + ;;
> > + mofi3500-3gn)
> > + set_usb_led "mofi3500-3gn:green:usb"
> > + ;;
> > + nw718)
> > + set_usb_led "nw718:amber:usb"
> > + ;;
> > + *)
> > + echo "leds: no setup defined for this board"
>
> Please remove this message. Not all boards require a custom LED configuration,
> and it would be confusing to print the message on those. Additionally, a ';;'
> is
> missing.
Ok, I will resend it.
--
Alexander
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] maccalc: add option to read mac from temp file
В Mon, 19 Sep 2011 00:27:35 +0300 Roman Yeryomin пишет: > On 19 September 2011 00:25, Alexander Gordeev wrote: > > В Mon, 19 Sep 2011 00:22:01 +0300 > > Roman Yeryomin пишет: > > > >> >> I'll test your patch. > >> > > >> > Yes, please. > >> > >> maybe your solution is better but reading from temp file also works > >> (didn't have any failure in 10k reads) > > > > So, does my patch fix the problem? > > yes, sorry, didn't mention that Ok, thanks for the test! Well, I think that in this situation my patch is a "fix" (because reading from a pipe is a quite natural thing in *nix) and your patch is a "new feature". So both could be applied. I can do a resend of both if you don't mind. -- Alexander signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] maccalc: add option to read mac from temp file
В Mon, 19 Sep 2011 00:22:01 +0300 Roman Yeryomin пишет: > >> I'll test your patch. > > > > Yes, please. > > maybe your solution is better but reading from temp file also works > (didn't have any failure in 10k reads) So, does my patch fix the problem? -- Alexander signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] ramips: combine led setup for all boards in one file
This removes unnecessary duplication and simplifies led setup for new
boards. It would be a one line change most likely.
Signed-off-by: Alexander Gordeev
---
.../ramips/base-files/etc/uci-defaults/fonera20n | 24 -
.../ramips/base-files/etc/uci-defaults/hw550-3g| 24 -
.../linux/ramips/base-files/etc/uci-defaults/leds | 36
.../base-files/etc/uci-defaults/mofi3500-3gn | 24 -
.../linux/ramips/base-files/etc/uci-defaults/nw718 | 13 ---
5 files changed, 36 insertions(+), 85 deletions(-)
delete mode 100755 target/linux/ramips/base-files/etc/uci-defaults/fonera20n
delete mode 100755 target/linux/ramips/base-files/etc/uci-defaults/hw550-3g
create mode 100755 target/linux/ramips/base-files/etc/uci-defaults/leds
delete mode 100755 target/linux/ramips/base-files/etc/uci-defaults/mofi3500-3gn
diff --git a/target/linux/ramips/base-files/etc/uci-defaults/fonera20n
b/target/linux/ramips/base-files/etc/uci-defaults/fonera20n
deleted file mode 100755
index 006f805..000
--- a/target/linux/ramips/base-files/etc/uci-defaults/fonera20n
+++ /dev/null
@@ -1,24 +0,0 @@
-#!/bin/sh
-#
-# Copyright (C) 2011 OpenWrt.org
-#
-
-fonera20n_set_leds() {
- uci batch <https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/2] ramips: combine network setup for all boards in one file
Inspired by the patch from Roman Yeryomin. Thanks, Roman!
This removes unnecessary duplication and simplifies network setup for new
boards. It would be a one line change most likely.
Signed-off-by: Alexander Gordeev
---
.../ramips/base-files/etc/uci-defaults/network | 117 +++-
.../linux/ramips/base-files/etc/uci-defaults/nw718 | 36 --
2 files changed, 91 insertions(+), 62 deletions(-)
delete mode 100755 target/linux/ramips/base-files/etc/uci-defaults/nw718
diff --git a/target/linux/ramips/base-files/etc/uci-defaults/network
b/target/linux/ramips/base-files/etc/uci-defaults/network
index fa35a45..6601621 100755
--- a/target/linux/ramips/base-files/etc/uci-defaults/network
+++ b/target/linux/ramips/base-files/etc/uci-defaults/network
@@ -1,7 +1,13 @@
#!/bin/sh
+. /etc/functions.sh
. /lib/ramips.sh
+if [ ! -x /usr/sbin/maccalc ]; then
+ echo "$0: maccalc not found!"
+ return
+fi
+
create_lan_wan()
{
uci batch <&2
+ return
+ fi
- [ -z $(which maccalc) ] && echo "set-macs: maccalc not found!" && return
+ dd bs=1 skip=$seek count=6 if=$part 2>/dev/null | /usr/sbin/maccalc
bin2mac
+}
- . /etc/functions.sh
+get_mac_nvram()
+{
+ local mtdname="$1"
+ local key="$2"
+ local part
+ local mac_dirty
- part=$(find_mtd_part "$mtdname")
- [ -z $part ] && echo "set-macs: partition $mtdname not found!" && return
+ part=$(find_mtd_part "$mtdname")
+ if [ -z "$part" ]; then
+ echo "get_mac_nvram: partition $mtdname not found!" >&2
+ return
+ fi
- dd bs=1 skip=$seek count=6 if=$part of=/tmp/mac.bin 2>/dev/null
- lan_mac=$(maccalc bin2mac /tmp/mac.bin)
- [ -z $lan_mac ] && echo "set-macs: can't extract mac address from
$part" && return
+ mac_dirty=$(strings "$part" | sed -n 's/'"$key"'=//p')
+ # "canonicalize" mac
+ maccalc add "$mac_dirty" 0
+}
- wan_mac=$(maccalc add $lan_mac 1)
+set_macs()
+{
+ local lan_mac="$1"
+ local wan_mac="$2"
- echo "Setting LAN mac address to: $lan_mac"
- echo "Setting WAN mac address to: $wan_mac"
+ echo "Setting LAN mac address to: $lan_mac" >&2
+ echo "Setting WAN mac address to: $wan_mac" >&2
- uci batch <&2
+ return
+ fi
+
+ set_macs_only_lan "$lan_mac"
+}
+
+set_macs_only_lan_from_nvram()
+{
+ local mtdname="$1"
+ local key="$2"
+ local lan_mac
+
+ lan_mac=$(get_mac_nvram "$mtdname" "$key")
+ if [ -z $lan_mac ]; then
+ echo "set_macs_only_lan_from_nvram: can't extract mac address
from $part" >&2
+ return
+ fi
+
+ set_macs_only_lan "$lan_mac"
+}
+
board=$(ramips_board_name)
case $board in
- f5d8235-v2)
- set_macs "u-boot" 262148
- ;;
- argus-atp52b | \
- nw718)
- set_macs "factory" 4
- ;;
- *)
- echo "set-macs: don't know where to get mac address on this
board"
+ f5d8235-v2)
+ create_lan_wan
+ set_macs_only_lan_from_mtd "u-boot" 262148
+ ;;
+ argus-atp52b | \
+ nw718)
+ create_lan_wan
+ set_macs_only_lan_from_mtd "factory" 4
+ ;;
+ *)
+ echo "network: no network setup for this board defined" >&2
esac
diff --git a/target/linux/ramips/base-files/etc/uci-defaults/nw718
b/target/linux/ramips/base-files/etc/uci-defaults/nw718
deleted file mode 100755
index 6fd96df..000
--- a/target/linux/ramips/base-files/etc/uci-defaults/nw718
+++ /dev/null
@@ -1,36 +0,0 @@
-#!/bin/sh
-#
-# Copyright (C) 2011 OpenWrt.org
-#
-
-nw718_set_macs() {
- local part
- local lan_mac
- local wan_mac
-
- [ -z $(which maccalc) ] && return
-
- . /etc/functions.sh
-
- part=$(find_mtd_part "factory")
- [ -z $part ] && return
-
- lan_mac=$(dd bs=1 skip=4 count=6 if=$part 2>/dev/null | maccalc bin2mac)
- [ -z $lan_mac ] && return
-
- wan_mac=$(maccalc add $lan_mac 1)
-
- uci batch <https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] maccalc: add option to read mac from temp file
В Sun, 18 Sep 2011 22:02:51 +0200 Gert Doering пишет: > Hi, > > On Sun, Sep 18, 2011 at 10:58:23PM +0400, Alexander Gordeev wrote: > > BTW you shouldn't even expect to read() 6 bytes from file at once. > > For normal files, read() will never read less than requested, unless you > hit an error or eof. Right. But then user decides to make a named pipe instead of a normal file, then the program fails. I meant something like this. > > $ strace -f -e trace=read,write sh -c 'dd if=/dev/urandom bs=1 count=6 > > | cat > /dev/null' > > /dev/urandom is not a *file*... > > > cat tries to read 32768 but gets 1 byte on every read. > > ... and cat does not read from /dev/urandom in the first place here, but > from the pipe from dd. It was primarily an example of read() from pipe behaviour. /dev/urandom was chosen randomly. :) -- Alexander signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] maccalc: add option to read mac from temp file
В Sun, 18 Sep 2011 21:30:09 +0300 Roman Yeryomin пишет: > On 18 September 2011 20:51, Alexander Gordeev wrote: > > В Fri, 16 Sep 2011 18:06:15 +0300 > > Roman Yeryomin пишет: > > > >> On 16 September 2011 17:51, Alexander Gordeev > >> wrote: > >> > В Fri, 16 Sep 2011 17:41:37 +0300 > >> > Roman Yeryomin пишет: > >> > > >> >> On 16 September 2011 01:40, Alexander Gordeev > >> >> wrote: > >> >> > В Fri, 26 Aug 2011 04:30:43 +0300 > >> >> > Roman Yeryomin пишет: > >> >> > > >> >> >> This method is much more stable than reading dd's output via stdin. > >> >> > > >> >> > What kind of problems do you have with piping dd's output to stdin? > >> >> > > >> >> > >> >> It outputs garbage very frequently and maccalc fails to convert the > >> >> mac (and as a consequence uci-default script fails to set the real mac > >> >> address). Try dd without piping to maccalc and you'll see. > >> >> I've noticed this bug on ramips platform and can't say anything about > >> >> other boards. > >> > > >> > Well, then this is probably a bug in dd? Or uClibc? Or kernel? > >> > Ok, I'll try to reproduce it. Can you please tell me what exactly is > >> > happening? > >> > > >> > >> Two different reads: > >> root@OpenWrt:/# dd bs=1 skip=262148 count=6 if=/dev/mtd0 > >> "u���6+0 records in > >> 6+0 records out > >> root@OpenWrt:/# dd bs=1 skip=262148 count=6 if=/dev/mtd0 > >> "u���6+0 records in > >> 6+0 records out > >> > >> I don't think this is the bug in dd/kernel/uclibc - it would probably > >> expose when writing to a file too. > >> Maybe it's something with busybox. I'm not sure of cause. > > > > The bug is in maccalc. It does a single read() and expects to get > > everything in one shot which doesn't happen sometimes. The patch is > > attached. It fixes the problem according to my tests. > > > > I don't know whether Roman's change is necessary anymore. What do you > > think, Roman? > > > > I think how it can be that you can't read 6 bytes from stdin in one > attempt but can do it from file? Quite easyly. BTW you shouldn't even expect to read() 6 bytes from file at once. For example: $ strace -f -e trace=read,write sh -c 'dd if=/dev/urandom bs=1 count=6 | cat > /dev/null' ... [pid 9661] read(0, ... [pid 9660] read(0, "}", 1) = 1 [pid 9660] write(1, "}", 1)= 1 [pid 9661] <... read resumed> "}", 32768) = 1 [pid 9661] write(1, "}", 1)= 1 [pid 9660] read(0, [pid 9661] read(0, [pid 9660] <... read resumed> "\320", 1) = 1 [pid 9660] write(1, "\320", 1) = 1 [pid 9661] <... read resumed> "\320", 32768) = 1 [pid 9660] read(0, [pid 9661] write(1, "\320", 1) = 1 [pid 9660] <... read resumed> "x", 1) = 1 [pid 9661] read(0, [pid 9660] write(1, "x", 1)= 1 [pid 9661] <... read resumed> "x", 32768) = 1 [pid 9661] write(1, "x", 1)= 1 [pid 9661] read(0, [pid 9660] read(0, "\36", 1) = 1 [pid 9660] write(1, "\36", 1) = 1 [pid 9661] <... read resumed> "\36", 32768) = 1 [pid 9661] write(1, "\36", 1) = 1 [pid 9660] read(0, [pid 9661] read(0, [pid 9660] <... read resumed> "\24", 1) = 1 [pid 9660] write(1, "\24", 1) = 1 [pid 9661] <... read resumed> "\24", 32768) = 1 [pid 9661] write(1, "\24", 1) = 1 [pid 9661] read(0, [pid 9660] read(0, "\372", 1) = 1 [pid 9660] write(1, "\372", 1) = 1 [pid 9661] <... read resumed> "\372", 32768) = 1 [pid 9661] write(1, "\372", 1) = 1 [pid 9661] read(0, "", 32768) = 0 ... cat tries to read 32768 but gets 1 byte on every read. And, well, please read 'man 2 read'. > It doesn't "happen sometimes", it's about 50 to 70% of failed reads. > And it's not about the boards - I've tested on 3 completely different > ones. Ok, it happens often. The more the value of the fix is. > I think that there is something to do with terminal translating binary > information into something unexpected. I forgot to mention that error >
Re: [OpenWrt-Devel] [PATCH] maccalc: add option to read mac from temp file
В Fri, 16 Sep 2011 18:06:15 +0300
Roman Yeryomin пишет:
> On 16 September 2011 17:51, Alexander Gordeev wrote:
> > В Fri, 16 Sep 2011 17:41:37 +0300
> > Roman Yeryomin пишет:
> >
> >> On 16 September 2011 01:40, Alexander Gordeev
> >> wrote:
> >> > В Fri, 26 Aug 2011 04:30:43 +0300
> >> > Roman Yeryomin пишет:
> >> >
> >> >> This method is much more stable than reading dd's output via stdin.
> >> >
> >> > What kind of problems do you have with piping dd's output to stdin?
> >> >
> >>
> >> It outputs garbage very frequently and maccalc fails to convert the
> >> mac (and as a consequence uci-default script fails to set the real mac
> >> address). Try dd without piping to maccalc and you'll see.
> >> I've noticed this bug on ramips platform and can't say anything about
> >> other boards.
> >
> > Well, then this is probably a bug in dd? Or uClibc? Or kernel?
> > Ok, I'll try to reproduce it. Can you please tell me what exactly is
> > happening?
> >
>
> Two different reads:
> root@OpenWrt:/# dd bs=1 skip=262148 count=6 if=/dev/mtd0
> "u���6+0 records in
> 6+0 records out
> root@OpenWrt:/# dd bs=1 skip=262148 count=6 if=/dev/mtd0
> "u���6+0 records in
> 6+0 records out
>
> I don't think this is the bug in dd/kernel/uclibc - it would probably
> expose when writing to a file too.
> Maybe it's something with busybox. I'm not sure of cause.
The bug is in maccalc. It does a single read() and expects to get
everything in one shot which doesn't happen sometimes. The patch is
attached. It fixes the problem according to my tests.
I don't know whether Roman's change is necessary anymore. What do you
think, Roman?
--
Alexander
From ae35ee0ce9fc9b6cb5d8bea0a5a059df71602eab Mon Sep 17 00:00:00 2001
From: Alexander Gordeev
Date: Sun, 18 Sep 2011 21:43:12 +0400
Subject: [PATCH] maccalc: don't expect to get all data in one read
Signed-off-by: Alexander Gordeev
---
package/maccalc/src/main.c | 31 ++-
1 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/package/maccalc/src/main.c b/package/maccalc/src/main.c
index e1e12cd..dcb5f55 100644
--- a/package/maccalc/src/main.c
+++ b/package/maccalc/src/main.c
@@ -9,6 +9,7 @@
*
*/
+#include
#include
#include
#include
@@ -124,6 +125,34 @@ static int maccalc_do_mac2bin(int argc, const char *argv[])
return 0;
}
+static ssize_t read_safe(int fd, void *buf, size_t count)
+{
+ ssize_t total = 0;
+ ssize_t r;
+
+ while(count > 0) {
+ r = read(fd, buf, count);
+ if (r == 0)
+ /* EOF */
+ break;
+ if (r < 0) {
+ if (errno == EINTR)
+/* interrupted by a signal, restart */
+continue;
+ /* error */
+ total = -1;
+ break;
+ }
+
+ /* ok */
+ total += r;
+ count -= r;
+ buf += r;
+ }
+
+ return total;
+}
+
static int maccalc_do_bin2mac(int argc, const char *argv[])
{
unsigned char mac[MAC_ADDRESS_LEN];
@@ -134,7 +163,7 @@ static int maccalc_do_bin2mac(int argc, const char *argv[])
return ERR_INVALID;
}
- c = read(STDIN_FILENO, mac, sizeof(mac));
+ c = read_safe(STDIN_FILENO, mac, sizeof(mac));
if (c != sizeof(mac)) {
fprintf(stderr, "failed to read from stdin\n");
return ERR_IO;
--
1.7.5.4
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: add set-macs uci-default script
Hi,
Your patch is mangled (by your e-mail client most likely).
Also I'm currently working on moving set-macs to network script entirely
(inspired by your patch :)). This is more natural because both scripts
work with the same config and also network script needs rework too.
It's for devices that have a full-blown switch. I have on that has only
one ethernet port. I think setting leds should be done in the same way,
not spreading through per-board files.
В Fri, 26 Aug 2011 04:33:30 +0300
Roman Yeryomin пишет:
> Signed-off-by: Roman Yeryomin
>
> Index: target/linux/ramips/base-files/etc/uci-defaults/nw718
> ===
> --- a/target/linux/ramips/base-files/etc/uci-defaults/nw718 (revision
> 28007)
> +++ b/target/linux/ramips/base-files/etc/uci-defaults/nw718 (working copy)
> @@ -3,30 +3,6 @@
> # Copyright (C) 2011 OpenWrt.org
> #
>
> -nw718_set_macs() {
> - local part
> - local lan_mac
> - local wan_mac
> -
> - [ -z $(which maccalc) ] && return
> -
> - . /etc/functions.sh
> -
> - part=$(find_mtd_part "factory")
> - [ -z $part ] && return
> -
> - lan_mac=$(dd bs=1 skip=4 count=6 if=$part 2>/dev/null | maccalc
> bin2mac)
> - [ -z $lan_mac ] && return
> -
> - wan_mac=$(maccalc add $lan_mac 1)
> -
> - uci batch < -set network.lan.macaddr='$lan_mac'
> -set network.wan.macaddr='$wan_mac'
> -commit network
> -EOF
> -}
> -
> nw718_set_leds() {
> uci batch < set system.usb_led=led
> @@ -45,5 +21,4 @@
>
> if [ "${board}" == "nw718" ]; then
> nw718_set_leds
> - nw718_set_macs
> fi
> Index: target/linux/ramips/base-files/etc/uci-defaults/set-macs
> ===
> --- a/target/linux/ramips/base-files/etc/uci-defaults/set-macs (revision 0)
> +++ b/target/linux/ramips/base-files/etc/uci-defaults/set-macs (revision 0)
> @@ -0,0 +1,52 @@
> +#!/bin/sh
> +#
> +# Copyright (C) 2011 OpenWrt.org
> +#
> +
> +set_macs() {
> + local mtdname=$1
> + local seek=$2
> + local part
> + local lan_mac
> + local wan_mac
> +
> + [ -z $(which maccalc) ] && echo "set-macs: maccalc not found!" &&
> return
> +
> + . /etc/functions.sh
> +
> + part=$(find_mtd_part "$mtdname")
> + [ -z $part ] && echo "set-macs: partition $mtdname not found!" &&
> return
> +
> + dd bs=1 skip=$seek count=6 if=$part of=/tmp/mac.bin 2>/dev/null
> + lan_mac=$(maccalc bin2mac /tmp/mac.bin)
> + [ -z $lan_mac ] && echo "set-macs: can't extract mac address
> from $part" && return
> +
> + wan_mac=$(maccalc add $lan_mac 1)
> +
> + echo "Setting LAN mac address to: $lan_mac"
> + echo "Setting WAN mac address to: $wan_mac"
> +
> + uci batch < +set network.lan.macaddr='$lan_mac'
> +set network.wan.macaddr='$wan_mac'
> +commit network
> +EOF
> +}
> +
> +. /lib/ramips.sh
> +
> +board=$(ramips_board_name)
> +
> +case $board in
> + f5d8235-v2)
> + set_macs "u-boot" 262148
> + ;;
> + argus-atp52b | \
> + nw718)
> + set_macs "factory" 4
> + ;;
> + *)
> + echo "set-macs: don't know where to get mac address on
> this board"
> +esac
> +
> +uci commit network
>
> Property changes on: target/linux/ramips/base-files/etc/uci-defaults/set-macs
> ___
> Added: svn:executable
>+ *
--
Alexander
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] maccalc: add option to read mac from temp file
В Fri, 16 Sep 2011 17:41:37 +0300 Roman Yeryomin пишет: > On 16 September 2011 01:40, Alexander Gordeev wrote: > > В Fri, 26 Aug 2011 04:30:43 +0300 > > Roman Yeryomin пишет: > > > >> This method is much more stable than reading dd's output via stdin. > > > > What kind of problems do you have with piping dd's output to stdin? > > > > It outputs garbage very frequently and maccalc fails to convert the > mac (and as a consequence uci-default script fails to set the real mac > address). Try dd without piping to maccalc and you'll see. > I've noticed this bug on ramips platform and can't say anything about > other boards. Well, then this is probably a bug in dd? Or uClibc? Or kernel? Ok, I'll try to reproduce it. Can you please tell me what exactly is happening? -- Alexander signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] maccalc: add option to read mac from temp file
В Fri, 26 Aug 2011 04:30:43 +0300 Roman Yeryomin пишет: > This method is much more stable than reading dd's output via stdin. What kind of problems do you have with piping dd's output to stdin? -- Alexander signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] usb on Asus WL500gPv2 not working
В Thu, 1 Sep 2011 14:01:19 +0400 Alexander Gordeev пишет: > В Thu, 01 Sep 2011 09:28:49 +0200 > "Ithamar R. Adema" пишет: > > > On Thu, 2011-09-01 at 04:36 +0400, Alexander Gordeev wrote: > > > Index '5' of cc_to_error is described as 'device not responding' in > > > the comments. I don't know what to do now. Maybe someone familiar with > > > ohci can help me? > > > > How many USB ports does the device have? It looks like it is actually > > communicating to a device, but if you have nothing connected it might be > > a hub built into the device... > > The device has 2 USB ports. Yes, I have nothing connected. I think, > it's a built-in hub indeed. This is a hardware bug. I should have trusted the fine software. :) Sorry for the noise. Just tested the same firmware on a different WL500gPv2 and it worked. Then I tried stable firmware from code.google.com/p/wl500g on the first router and it showed the same errors. -- Alexander signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] usb on Asus WL500gPv2 not working
В Thu, 01 Sep 2011 09:28:49 +0200 "Ithamar R. Adema" пишет: > On Thu, 2011-09-01 at 04:36 +0400, Alexander Gordeev wrote: > > Index '5' of cc_to_error is described as 'device not responding' in > > the comments. I don't know what to do now. Maybe someone familiar with > > ohci can help me? > > How many USB ports does the device have? It looks like it is actually > communicating to a device, but if you have nothing connected it might be > a hub built into the device... The device has 2 USB ports. Yes, I have nothing connected. I think, it's a built-in hub indeed. -- Alexander signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] usb on Asus WL500gPv2 not working
В Wed, 31 Aug 2011 16:02:43 +0400 Alexander Gordeev пишет: > В Wed, 31 Aug 2011 13:44:27 +0200 > Florian Fainelli пишет: > > > Hello, > > > > On Wednesday 31 August 2011 13:29:45 Alexander Gordeev wrote: > > > Hi! > > > > > > Usb ports on my Asus WL500gPv2 do not work with the latest trunk. I > > > tried to build a fresh checkout. Full log is attached. Here is what I > > > think is the problem: > > > > > > usb 1-1: device descriptor read/64, error -62 > > > usb 1-1: device descriptor read/64, error -62 > > > usb 1-1: new full speed USB device number 3 using ohci_hcd > > > usb 1-1: device descriptor read/64, error -62 > > > usb 1-1: device descriptor read/64, error -62 > > > usb 1-1: new full speed USB device number 4 using ohci_hcd > > > usb 1-1: device not accepting address 4, error -62 > > > usb 1-1: new full speed USB device number 5 using ohci_hcd > > > usb 1-1: device not accepting address 5, error -62 > > > hub 1-0:1.0: unable to enumerate USB device on port 1 > > > > > > What can I do to fix this? > > > > Are you sure this is not an issue with the USB slave device? It looks to me > > like the device might not be responding correctly, or maybe it's drowing > > too > > much power. > > > > This could be a genuine ssb-ohci bug anyway. > > I'm sure because this is a part of boot log (when the ohci driver is > loaded, I think) and I didn't plug any device into the port. > I plugged a device after the boot and it neither printed anything on > console nor appear in the /proc/bus/usb/devices. I tried to find out what's up. Here is a new trace: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver ohci_hcd ssb0:1: SSB OHCI Controller ohci_hcd ssb0:1: new USB bus registered, assigned bus number 1 ohci_hcd ssb0:1: irq 6, io mem 0x18003000 hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected ohci_hcd ssb0:1: SSB EHCI Controller ohci_hcd ssb0:1: new USB bus registered, assigned bus number 2 ohci_hcd ssb0:1: irq 6, io mem 0x18003800 ohci_hcd ssb0:1: USB 0.0 started, EHCI 1.00 hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected uhci_hcd: USB Universal Host Controller Interface driver usb 1-1: new full speed USB device number 2 using ohci_hcd drivers/usb/core/hub.c:2927: hub_port_init: dive in drivers/usb/host/ohci-q.c:1088: takeback_td drivers/usb/host/ohci-q.c:766: td_done: hwInfo=0x5ec2 cc_to_error[5]=-62 drivers/usb/core/hub.c:2933: hub_port_init: ret=-62 drivers/usb/core/hub.c:2927: hub_port_init: dive in drivers/usb/host/ohci-q.c:1088: takeback_td drivers/usb/host/ohci-q.c:766: td_done: hwInfo=0x5ec2 cc_to_error[5]=-62 drivers/usb/core/hub.c:2933: hub_port_init: ret=-62 drivers/usb/core/hub.c:2927: hub_port_init: dive in drivers/usb/host/ohci-q.c:1088: takeback_td drivers/usb/host/ohci-q.c:766: td_done: hwInfo=0x5ec2 cc_to_error[5]=-62 drivers/usb/core/hub.c:2933: hub_port_init: ret=-62 usb 1-1: device descriptor read/64, error -62 drivers/usb/core/hub.c:2927: hub_port_init: dive in drivers/usb/host/ohci-q.c:1088: takeback_td drivers/usb/host/ohci-q.c:766: td_done: hwInfo=0x5ec2 cc_to_error[5]=-62 drivers/usb/core/hub.c:2933: hub_port_init: ret=-62 drivers/usb/core/hub.c:2927: hub_port_init: dive in drivers/usb/host/ohci-q.c:1088: takeback_td drivers/usb/host/ohci-q.c:766: td_done: hwInfo=0x5ec2 cc_to_error[5]=-62 drivers/usb/core/hub.c:2933: hub_port_init: ret=-62 drivers/usb/core/hub.c:2927: hub_port_init: dive in drivers/usb/host/ohci-q.c:1088: takeback_td drivers/usb/host/ohci-q.c:766: td_done: hwInfo=0x5ec2 cc_to_error[5]=-62 drivers/usb/core/hub.c:2933: hub_port_init: ret=-62 usb 1-1: device descriptor read/64, error -62 usb 1-1: new full speed USB device number 3 using ohci_hcd drivers/usb/core/hub.c:2927: hub_port_init: dive in drivers/usb/host/ohci-q.c:1088: takeback_td drivers/usb/host/ohci-q.c:766: td_done: hwInfo=0x5ec2 cc_to_error[5]=-62 drivers/usb/core/hub.c:2933: hub_port_init: ret=-62 drivers/usb/core/hub.c:2927: hub_port_init: dive in drivers/usb/host/ohci-q.c:1088: takeback_td drivers/usb/host/ohci-q.c:766: td_done: hwInfo=0x5ec2 cc_to_error[5]=-62 drivers/usb/core/hub.c:2933: hub_port_init: ret=-62 drivers/usb/core/hub.c:2927: hub_port_init: dive in drivers/usb/host/ohci-q.c:1088: takeback_td drivers/usb/host/ohci-q.c:766: td_done: hwInfo=0x5ec2 cc_to_error[5]=-62 drivers/usb/core/hub.c:2933: hub_port_init: ret=-62 usb 1-1: device descriptor read/64, error -62 drivers/usb/core/hub.c:2927: hub_port_init: dive in drivers/usb/host/ohci-q.c:1088: takeback_td drivers/usb/host/ohci-q.c:766: td_done: hwInfo=0x5ec2 cc_to_error[5]=-62 drivers/usb/core/hub.c:2933: hub_port_init: ret=-62
Re: [OpenWrt-Devel] usb on Asus WL500gPv2 not working
В Wed, 31 Aug 2011 13:44:27 +0200 Florian Fainelli пишет: > Hello, > > On Wednesday 31 August 2011 13:29:45 Alexander Gordeev wrote: > > Hi! > > > > Usb ports on my Asus WL500gPv2 do not work with the latest trunk. I > > tried to build a fresh checkout. Full log is attached. Here is what I > > think is the problem: > > > > usb 1-1: device descriptor read/64, error -62 > > usb 1-1: device descriptor read/64, error -62 > > usb 1-1: new full speed USB device number 3 using ohci_hcd > > usb 1-1: device descriptor read/64, error -62 > > usb 1-1: device descriptor read/64, error -62 > > usb 1-1: new full speed USB device number 4 using ohci_hcd > > usb 1-1: device not accepting address 4, error -62 > > usb 1-1: new full speed USB device number 5 using ohci_hcd > > usb 1-1: device not accepting address 5, error -62 > > hub 1-0:1.0: unable to enumerate USB device on port 1 > > > > What can I do to fix this? > > Are you sure this is not an issue with the USB slave device? It looks to me > like the device might not be responding correctly, or maybe it's drowing too > much power. > > This could be a genuine ssb-ohci bug anyway. I'm sure because this is a part of boot log (when the ohci driver is loaded, I think) and I didn't plug any device into the port. I plugged a device after the boot and it neither printed anything on console nor appear in the /proc/bus/usb/devices. -- Alexander signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] usb on Asus WL500gPv2 not working
Hi! Usb ports on my Asus WL500gPv2 do not work with the latest trunk. I tried to build a fresh checkout. Full log is attached. Here is what I think is the problem: usb 1-1: device descriptor read/64, error -62 usb 1-1: device descriptor read/64, error -62 usb 1-1: new full speed USB device number 3 using ohci_hcd usb 1-1: device descriptor read/64, error -62 usb 1-1: device descriptor read/64, error -62 usb 1-1: new full speed USB device number 4 using ohci_hcd usb 1-1: device not accepting address 4, error -62 usb 1-1: new full speed USB device number 5 using ohci_hcd usb 1-1: device not accepting address 5, error -62 hub 1-0:1.0: unable to enumerate USB device on port 1 What can I do to fix this? -- Alexander Linux version 3.0.3 (alex@desktopvm) (gcc version 4.5.4 20110808 (prerelease) (Linaro GCC 4.5-2011.08) ) #1 Wed Aug 31 15:08:13 MSK 2011 CPU revision is: 00029029 (Broadcom BMIPS3300) bcm47xx: using ssb bus ssb: chipcommon status is 0x0 ssb: Initializing MIPS core... ssb: set_irq: core 0x0806, irq 4 => 4 ssb: set_irq: core 0x0816, irq 5 => 2 ssb: set_irq: core 0x0812, irq 2 => 5 ssb: after irq reconfiguration ssb: core 0x0800, irq : 2(S) 3* 4 5 6 D I ssb: core 0x0806, irq : 2(S) 3 4* 5 6 D I ssb: core 0x0816, irq : 2(S)* 3 4 5 6 D I ssb: core 0x0819, irq : 2(S) 3 4 5 6* D I ssb: core 0x080f, irq : 2(S) 3 4 5 6 D I* ssb: core 0x0812, irq : 2(S) 3 4 5* 6 D I ssb: core 0x081c, irq : 2(S) 3 4 5 6 D I* found parallel flash. ssb: Sonics Silicon Backplane found at address 0x1800 Determined physical RAM map: memory: 0200 @ (usable) Initrd not found or empty - disabling initrd Zone PFN ranges: Normal 0x -> 0x2000 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x -> 0x2000 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128 Kernel command line: root=/dev/mtdblock2 rootfstype=squashfs,jffs2 noinitrd console=ttyS0,115200 PID hash table entries: 128 (order: -3, 512 bytes) Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) Inode-cache hash table entries: 2048 (order: 1, 8192 bytes) Primary instruction cache 16kB, VIPT, 4-way, linesize 16 bytes. Primary data cache 16kB, 2-way, VIPT, cache aliases, linesize 16 bytes Memory: 29400k/32768k available (2260k kernel code, 3368k reserved, 481k data, 156k init, 0k highmem) NR_IRQS:128 console [ttyS0] enabled Calibrating delay loop... 239.10 BogoMIPS (lpj=478208) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 512 NET: Registered protocol family 16 bio: create slab at 0 Switching to clocksource MIPS Switched to NOHz mode on CPU #0 NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 1024 (order: 1, 8192 bytes) TCP bind hash table entries: 1024 (order: 0, 4096 bytes) TCP: Hash tables configured (established 1024 bind 1024) TCP reno registered UDP hash table entries: 256 (order: 0, 4096 bytes) UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) NET: Registered protocol family 1 squashfs: version 4.0 (2009/01/31) Phillip Lougher JFFS2 version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc. msgmni has been set to 57 io scheduler noop registered io scheduler deadline registered (default) Serial: 8250/16550 driver, 2 ports, IRQ sharing enabled serial8250: ttyS0 at MMIO 0xb8000300 (irq = 3) is a U6_16550A serial8250: ttyS1 at MMIO 0xb8000400 (irq = 3) is a U6_16550A �erial8250.0: ttyS0 at MMIO 0xb8000300 (irq = 3) is a U6_16550A serial8250.0: ttyS1 at MMIO 0xb8000400 (irq = 3) is a U6_16550A bcm47xx_pflash: flash init: 0x1c00 0x0200 Physically mapped flash: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0xc2 Chip ID 0x0022cb Amd/Fujitsu Extended Query Table at 0x0040 Amd/Fujitsu Extended Query version 1.1. number of CFI chips: 1 bcm47xx_pflash: Flash device: 0x200 at 0x1fc0 bcm47xx_part: bootloader size: 131072 bcm47xx_part: Looking for dual image bcm47xx_part: TRX offset : 0 bcm47xx_part: Updating TRX offsets and length: bcm47xx_part: old trx = [0x001c, 0x0968, 0x000ec800], len=0x002d1000 crc32=0x0b0fa919 bcm47xx_part: new trx = [0x001c, 0x0968, 0x000ec800], len=0x000ec800 crc32=0x92014f46 bcm47xx_part: Done 4 bcm47xx partitions found on MTD device Physically mapped flash Creating 4 MTD partitions on "Physically mapped flash": 0x-0x0002 : "cfe" 0x0002-0x007f : "linux" 0x0010c800-0x007f : "rootfs" mtd: partition "rootfs" must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only mtd: partition "rootfs" set to be root filesystem mtd: partition "rootfs_data" created automatically, ofs=2B, len=54 0x002b-0x007f : "rootfs_data" 0x007f-0x0080 : "nvram" bcm47xx_sflash: error registering platform driver: -19 b
[OpenWrt-Devel] [PATCH 0/4] one fix and new packages
The first patch adds extra symlinks to the tools provided by lrzsz to help minicom find them. Patch 2 extracts libbz2 for bsdiff. Patches 3-4 add bsdiff and xdelta3 packages. These are binary diff and patch utils. Alexander Gordeev (4): lrzsz: create extra symlinks for minicom bzip2: build libbz2 package bsdiff: add bsdiff package xdelta3: add xdelta3 package lang/perl-compress-bzip2/Makefile |2 +- utils/bsdiff/Makefile | 42 utils/bsdiff/patches/001-makefile.patch| 11 + utils/bzip2/Makefile | 33 +-- utils/lrzsz/Makefile |6 +++ utils/xdelta3/Makefile | 42 .../patches/001-decrease-default-window-size.patch | 19 + 7 files changed, 149 insertions(+), 6 deletions(-) create mode 100644 utils/bsdiff/Makefile create mode 100644 utils/bsdiff/patches/001-makefile.patch create mode 100644 utils/xdelta3/Makefile create mode 100644 utils/xdelta3/patches/001-decrease-default-window-size.patch -- 1.7.5.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/4] bzip2: build libbz2 package
Build libbz2 and make bzip2 depend on it. libbz2 is necessary for packaging bsdiff. Also update perl-compress-bzip2 package accordingly. Signed-off-by: Alexander Gordeev --- lang/perl-compress-bzip2/Makefile |2 +- utils/bzip2/Makefile | 33 - 2 files changed, 29 insertions(+), 6 deletions(-) diff --git a/lang/perl-compress-bzip2/Makefile b/lang/perl-compress-bzip2/Makefile index de4c4f4..2e06373 100644 --- a/lang/perl-compress-bzip2/Makefile +++ b/lang/perl-compress-bzip2/Makefile @@ -20,7 +20,7 @@ define Package/perl-compress-bzip2 CATEGORY:=Languages TITLE:=Perl interface to bzip2 compression library URL:=http://search.cpan.org/dist/Compress-Bzip2/ - DEPENDS:=perl +bzip2 + DEPENDS:=perl +libbz2 endef define Build/Configure diff --git a/utils/bzip2/Makefile b/utils/bzip2/Makefile index a9d58a5..1cdfaa4 100644 --- a/utils/bzip2/Makefile +++ b/utils/bzip2/Makefile @@ -17,37 +17,60 @@ PKG_MD5SUM:=00b516f4704d4a7cb50a1d97e6e8e15b include $(INCLUDE_DIR)/package.mk +define Package/libbz2 + SECTION:=libs + CATEGORY:=Libraries + DEPENDS:= + TITLE:=bzip2 library. + URL:=http://www.bzip.org/ +endef + +define Package/libbz2/description + bzip2 is a freely available, patent free, high-quality + data compressor. This packages provides libbz2 library. +endef + define Package/bzip2 SECTION:=utils CATEGORY:=Utilities - DEPENDS:= + DEPENDS:=+libbz2 TITLE:=bzip2 is a compression utility. URL:=http://www.bzip.org/ endef define Package/bzip2/description bzip2 is a freely available, patent free, high-quality - data compressor. + data compressor. This package provides the binary. endef TARGET_CFLAGS += $(FPIC) CONFIGURE_ARGS += --prefix=/usr MAKE_FLAGS += \ + -f Makefile-libbz2_so \ CFLAGS="$(TARGET_CFLAGS)" \ LDFLAGS="$(TARGET_LDLAGS)" \ - bzip2 \ + all define Build/InstallDev $(INSTALL_DIR) $(1)/usr/include $(CP) $(PKG_BUILD_DIR)/bzlib.h $(1)/usr/include/ $(INSTALL_DIR) $(1)/usr/lib - $(CP) $(PKG_BUILD_DIR)/libbz2.a $(1)/usr/lib/ + $(CP) $(PKG_BUILD_DIR)/libbz2.so.$(PKG_VERSION) $(1)/usr/lib/ + $(LN) libbz2.so.$(PKG_VERSION) $(1)/usr/lib/libbz2.so.1.0 + $(LN) libbz2.so.$(PKG_VERSION) $(1)/usr/lib/libbz2.so +endef + +define Package/libbz2/install + $(INSTALL_DIR) $(1)/usr/lib/ + $(CP) $(PKG_BUILD_DIR)/libbz2.so.$(PKG_VERSION) $(1)/usr/lib/ + $(LN) libbz2.so.$(PKG_VERSION) $(1)/usr/lib/libbz2.so.1.0 endef define Package/bzip2/install $(INSTALL_DIR) $(1)/usr/bin/ - $(INSTALL_BIN) $(PKG_BUILD_DIR)/$(PKG_NAME) $(1)/usr/bin/ + $(INSTALL_BIN) $(PKG_BUILD_DIR)/bzip2-shared $(1)/usr/bin/bzip2 endef +$(eval $(call BuildPackage,libbz2)) $(eval $(call BuildPackage,bzip2)) -- 1.7.5.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 4/4] xdelta3: add xdelta3 package
Signed-off-by: Alexander Gordeev --- utils/xdelta3/Makefile | 42 .../patches/001-decrease-default-window-size.patch | 19 + 2 files changed, 61 insertions(+), 0 deletions(-) create mode 100644 utils/xdelta3/Makefile create mode 100644 utils/xdelta3/patches/001-decrease-default-window-size.patch diff --git a/utils/xdelta3/Makefile b/utils/xdelta3/Makefile new file mode 100644 index 000..c33 --- /dev/null +++ b/utils/xdelta3/Makefile @@ -0,0 +1,42 @@ +# +# Copyright (C) 2011 Alexander Gordeev +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +include $(TOPDIR)/rules.mk + +PKG_NAME:=xdelta3 +PKG_VERSION:=3.0.0 +PKG_RELEASE:=1 + +PKG_SOURCE:=xdelta$(PKG_VERSION).tar.gz +PKG_SOURCE_URL:=http://xdelta.googlecode.com/files +PKG_MD5SUM:=5fe038be3a266d2a7913e10d1cec6d88 + +PKG_BUILD_DIR:=$(BUILD_DIR)/xdelta$(PKG_VERSION) + +include $(INCLUDE_DIR)/package.mk + +define Package/xdelta3 + SECTION:=utils + CATEGORY:=Utilities + URL:=http://xdelta.org + TITLE:=A diff utility which works with binary files +endef + +define Package/xdelta3/description + Xdelta3 is a set of tools designed to compute changes between binary + files. These changes (delta files) are similar to the output of the + "diff" program, in that they may be used to store and transmit only + the changes between files. The "delta files" that Xdelta3 manages are + stored in RFC3284 (VCDIFF) format. +endef + +define Package/xdelta3/install + $(INSTALL_DIR) $(1)/usr/bin + $(INSTALL_BIN) $(PKG_BUILD_DIR)/xdelta3 $(1)/usr/bin/ +endef + +$(eval $(call BuildPackage,xdelta3)) diff --git a/utils/xdelta3/patches/001-decrease-default-window-size.patch b/utils/xdelta3/patches/001-decrease-default-window-size.patch new file mode 100644 index 000..3fd134d --- /dev/null +++ b/utils/xdelta3/patches/001-decrease-default-window-size.patch @@ -0,0 +1,19 @@ +diff --git a/xdelta3.h b/xdelta3.h +index 5dafd8d..22bc37f 100644 +--- a/xdelta3.h b/xdelta3.h +@@ -38,12 +38,12 @@ + * buffer is used directly. + */ + #ifndef XD3_DEFAULT_WINSIZE +-#define XD3_DEFAULT_WINSIZE (1U << 23) ++#define XD3_DEFAULT_WINSIZE (1U << 16) + #endif + + /* Default total size of the source window used in xdelta3-main.h */ + #ifndef XD3_DEFAULT_SRCWINSZ +-#define XD3_DEFAULT_SRCWINSZ (1U << 26) ++#define XD3_DEFAULT_SRCWINSZ (1U << 19) + #endif + + /* When Xdelta requests a memory allocation for certain buffers, it -- 1.7.5.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/4] bsdiff: add bsdiff package
Signed-off-by: Alexander Gordeev
---
utils/bsdiff/Makefile | 42 +++
utils/bsdiff/patches/001-makefile.patch | 11
2 files changed, 53 insertions(+), 0 deletions(-)
create mode 100644 utils/bsdiff/Makefile
create mode 100644 utils/bsdiff/patches/001-makefile.patch
diff --git a/utils/bsdiff/Makefile b/utils/bsdiff/Makefile
new file mode 100644
index 000..2dab0ac
--- /dev/null
+++ b/utils/bsdiff/Makefile
@@ -0,0 +1,42 @@
+#
+# Copyright (C) 2011 Alexander Gordeev
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=bsdiff
+PKG_VERSION:=4.3
+PKG_RELEASE:=1
+
+PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
+PKG_SOURCE_URL:=http://www.daemonology.net/bsdiff
+PKG_MD5SUM:=e6d812394f0e0ecc8d5df255aa1db22a
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/bsdiff
+ SECTION:=utils
+ CATEGORY:=Utilities
+ DEPENDS:=+libbz2
+ URL:=http://www.daemonology.net/bsdiff
+ TITLE:=Tools for building and applying patches to binary files
+endef
+
+define Package/bsdiff/description
+ bsdiff and bspatch are tools for building and applying patches to binary
+ files. By using suffix sorting (specifically, Larsson and Sadakane's
+ qsufsort) and taking advantage of how executable files change, bsdiff
+ routinely produces binary patches 50-80% smaller than those produced by
+ Xdelta, and 15% smaller than those produced by .RTPatch (a $2750/seat
+ commercial patch tool).
+endef
+
+define Package/bsdiff/install
+ $(INSTALL_DIR) $(1)/usr/bin
+ $(INSTALL_BIN) $(PKG_BUILD_DIR)/bsdiff $(PKG_BUILD_DIR)/bspatch
$(1)/usr/bin/
+endef
+
+$(eval $(call BuildPackage,bsdiff))
diff --git a/utils/bsdiff/patches/001-makefile.patch
b/utils/bsdiff/patches/001-makefile.patch
new file mode 100644
index 000..45f3d6a
--- /dev/null
+++ b/utils/bsdiff/patches/001-makefile.patch
@@ -0,0 +1,11 @@
+diff --git a/Makefile b/Makefile
+index a522607..7da4463 100644
+--- a/Makefile
b/Makefile
+@@ -10,6 +10,3 @@ bspatch: bspatch.c
+
+ install:
+ ${INSTALL_PROGRAM} bsdiff bspatch ${PREFIX}/bin
+-.ifndef WITHOUT_MAN
+- ${INSTALL_MAN} bsdiff.1 bspatch.1 ${PREFIX}/man/man1
+-.endif
--
1.7.5.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/4] lrzsz: create extra symlinks for minicom
Minicom wants rz/rx/rb when asked to transfer a file. Signed-off-by: Alexander Gordeev --- utils/lrzsz/Makefile |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/utils/lrzsz/Makefile b/utils/lrzsz/Makefile index 6e93bad..640bb41 100644 --- a/utils/lrzsz/Makefile +++ b/utils/lrzsz/Makefile @@ -42,8 +42,14 @@ define Package/lrzsz/install (cd $(1)/usr/bin; \ ln -fs lrz lrx; \ ln -fs lrz lrb; \ + ln -fs lrz rz; \ + ln -fs lrz rx; \ + ln -fs lrz rb; \ ln -fs lsz lsx; \ ln -fs lsz lsb; \ + ln -fs lsz sz; \ + ln -fs lsz sx; \ + ln -fs lsz sb; \ ); endef -- 1.7.5.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] flash wearout
В Sun, 05 Jun 2011 22:08:01 -0700
Philip Prindeville пишет:
> On 6/5/11 10:54 AM, Peter Wagner wrote:
> > Am Freitag, 3. Mai 2011, 04:11:43 schrieb Philip Prindeville:
> >> On 5/31/11 10:48 AM, Peter Wagner wrote:
> >>> Am Dienstag, 31. Mai 2011, 17:52:58 schrieb Philip Prindeville:
> On 5/30/11 4:00 PM, Peter Wagner wrote:
> > Hi,
> >
> > while i was reading some init files i stumbled upon this:
> >
> > /sbin/wifi detect >> /etc/config/wireless
> >
> > grep -qs config /etc/config/wireless && {
> >
> > /sbin/wifi up
> >
> > } || {
> >
> > rm -f /etc/config/wireless
> >
> > }
> >
> > this means:
> >> /sbin/wifi detect >> /etc/config/wireless
> >
> > /sbin/wifi only outputs something if /etc/config/wireless doesnt exist
> > but even if the files exist /etc/config/wireless modification time gets
> > updated. this means even when the wifi is allready configured the
> > modtime of the file gets updated everytime the system boots.
> >
> > i created this patch - maybe there is a better way to fix this.
>
> I would test for the file changing with respect to the existing copy,
> rather than non-zero length.
>
> If you change out hardware, or if you had a wireless interface but now
> have removed it, you don't want to retain invalid information.
>
> I'd use "cmp -s" to compare the two files.
> >>>
> >>> this wont work - because if the file wireless exists the script output
> >>> nothing ... so if you attach a new wifi card - you would have to remove
> >>> the file and restart the router or do a wifi detect >
> >>> /etc/config/wireless ...
> >>>
> >>> and if the file is empty (the one wifi detect created) cmp will also
> >>> return something != 0...
> >>
> >> That's a glitch. Why should "wifi detect" care if there's a file already
> >> present or not? It should ignore it.
> >>
> >
> > yeah but if i have a /etc/config/wireless file and do a wifi detect i get
> > no
> > output - when i delete the file it gives me the standard file... like
> >
> > server /root # ls -la /etc/config/wireless
> > -rw-r--r--1 root root 321 Jan 27 00:27
> > /etc/config/wireless
> > server /root # wifi detect
> > server /root # rm /etc/config/wireless
> > server /root # wifi detect
> > config wifi-device radio0
> > option type mac80211
> > option channel 11
> > option macaddr xx:xx:xx:xx:xx:xx
> > option hwmode 11g
> >
> > # REMOVE THIS LINE TO ENABLE WIFI:
> > option disabled 1
> >
> > config wifi-iface
> > option device radio0
> > option network lan
> > option mode ap
> > option ssid OpenWrt
> > option encryption none
> >
> >
> > i modified the patch, now it doesnt use wc anymore
> >
> >
> > regards
> > Peter
>
> You misunderstand me. I'm saying that "wifi detect" should generate an output
> file regardless of whether /etc/config/wireless exists or not. Capture the
> output into /tmp, and if it's different from what's in /etc/config/wireless
> then copy it over.
Then if a user modified /etc/config/wireless, the changes will not
survive a reboot. That's no good.
Why not do something like:
test -s /etc/config/wireless || wifi detect > /etc/config/wireless
This should work both when 'wifi detect' generates output or not.
--
Alexander
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] flash wearout
В Mon, 30 May 2011 18:38:00 -0700
Philip Prindeville пишет:
> How often are you booting that this is even a concern?
Once or twice per day is enough?
I have a small router with a battery and USB port which you can plug
any USB 3g/4g modem in. It's quite handy to bring it with you and turn
on/off only when you need it.
> On 5/30/11 4:00 PM, Peter Wagner wrote:
> > Hi,
> >
> > while i was reading some init files i stumbled upon this:
> >
> > /sbin/wifi detect >> /etc/config/wireless
> >
> > grep -qs config /etc/config/wireless && {
> > /sbin/wifi up
> > } || {
> > rm -f /etc/config/wireless
> > }
> >
> > this means:
> >
> >> /sbin/wifi detect >> /etc/config/wireless
> >
> > /sbin/wifi only outputs something if /etc/config/wireless doesnt exist
> > but even if the files exist /etc/config/wireless modification time gets
> > updated. this means even when the wifi is allready configured the modtime
> > of
> > the file gets updated everytime the system boots.
> >
> > i created this patch - maybe there is a better way to fix this.
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
--
Alexander
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] RFC6204 for CPE routers
Sorry for the delay... В Wed, 30 Mar 2011 17:58:19 +0200 Felix Fietkau пишет: > On 2011-03-30 5:43 PM, Alexander Gordeev wrote: > > В Wed, 30 Mar 2011 17:17:01 +0200 > > Jo-Philipp Wich пишет: > > > >> Hi, > >> > >> no I have no list yet but it boils down to the fact that the current > >> network and interface setup mechanisms are rather constrained, old and > >> inflexible. > >> > >> Big problems are the lack of statefulness, the tendency for race > >> conditions, the inability to properly nest protocols and the limited > >> featureset of the ash shell which will not allow for complex interface > >> operations like calculating ULAs etc. > >> > >> Felix has started working on netifd, which will at some point supersede > >> the current network setup scripts with an rpc capable daemon written in > >> C for better access to kernel APIs, ability to listen on netlink events > >> etc. > >> > >> Once this is done, we can start to implement all the IPv6 requirements > >> in a clean way. > > > > Very interesting, but there are also projects like connman > > (connman.net) or network manager. I think the latter is bloated but the > > former is intended for embedded devices from the very beginning. What's > > wrong with connman? > connman seems to be centered around one specifific use case - having a > mobile device access the internet through multiple connections. > > netifd will be able to manage even complex interface configurations with > a mix of bonding, vlans, bridges, etc. and handle the dependencies > between interfaces properly - and of course all that without adding > unnecessary bloat. > > > BTW, what's the difference between ubus and dbus? I didn't find any > > documentation... > D-Bus is bloated, the pure C API is very annoying to use and requires > writing large amounts of boilerplate code. In fact, the pure C API is so > annoying that its API documentation even states: "If you use this > low-level API directly, you're signing up for some pain." > > ubus is tiny (12k library, 13k daemon, 6k CLI) and requires only two > small libraries (json-c for the CLI only, and libubox). > > It has the advantage of being easy to use from regular C code, as well > as automatically making all exported API functionality also available to > shell scripts with no extra effort. > > - Felix Very-very cool, good luck! Hope both projects will once supersede today's leaders not only in the embedded world. Looking forward for the first release of netifd. Hope I would be able to help you in some way. -- Alexander signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 7/7] ramips: enable USB
В Tue, 05 Apr 2011 10:45:29 -0500 Layne Edwards пишет: > > > > Hi Alexander, > > > > The kernel version for target ramips in the latest trunk has updated to > > 2.6.36.4. I changed it back to using 2.6.36.2 and dwc_otg is now back in > > business (except I still have to rmmod and insmod dwc_otg). I wondered what > > has been changed in 2.6.36.4. > > > > Thanks. > > -Vincent > > I am using the dwc_otg driver from the RaLink SDK in my ramips build. It's > the same driver used in fon-ng and dd-wrt (2.6.21 ramips targets), only > updated for recent kernels (2.6.37). USB is working flawlessly on my rt3052 > SoC routers. > > Not to supersede Alexander's patch, but this may be a better option for the > ramips target until the new dwc_otg driver gets included upstream... since > the RaLink SDK version is considered stable (and well tested). > > I will be happy to share if anyone is interested. I'm interested too! There are a couple of issues with my dwc_otg variant so it would be very interesting and useful to test yours too. -- Alexander signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] RFC6204 for CPE routers
В Wed, 30 Mar 2011 17:17:01 +0200 Jo-Philipp Wich пишет: > Hi, > > no I have no list yet but it boils down to the fact that the current > network and interface setup mechanisms are rather constrained, old and > inflexible. > > Big problems are the lack of statefulness, the tendency for race > conditions, the inability to properly nest protocols and the limited > featureset of the ash shell which will not allow for complex interface > operations like calculating ULAs etc. > > Felix has started working on netifd, which will at some point supersede > the current network setup scripts with an rpc capable daemon written in > C for better access to kernel APIs, ability to listen on netlink events etc. > > Once this is done, we can start to implement all the IPv6 requirements > in a clean way. Very interesting, but there are also projects like connman (connman.net) or network manager. I think the latter is bloated but the former is intended for embedded devices from the very beginning. What's wrong with connman? BTW, what's the difference between ubus and dbus? I didn't find any documentation... -- Alexander signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/7] ramips usb support
В Sat, 05 Feb 2011 15:14:11 +0100 "Imre Kaloz" пишет: > On Sat, 05 Feb 2011 11:25:02 +0100, John Crispin wrote: > > > i think the ppc people are pushing a version upstream. until it is ready > > i think it is best to just support several versions and then add glue > > code later for the upstream version. merging the trees now would result > > in duplicating part of the merging as we will eventually have to go with > > the upstream version anyway > > Nah. Merge the upstream-ready stuff to generic, and add the glue now. The patches in linuxppc-dev are not upstream-ready yet. Moreover my patches are based on a version 5 of the patchset while there is already version 9. This is ok for now because there were no major new features/bugfixes and also some very strange things sneaked in to the latest versions. They are being discussed. When all the issues are solved I'll use the latest patchset. But it can take quite some time. At the moment I'd rather merge my stuff as is. :) BTW I surely can't aid much in merging my patches to generic at the moment because I have other very urgent tasks. -- Alexander signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 7/7] ramips: enable USB
В Fri, 11 Feb 2011 18:06:06 +0800 HP Teoh пишет: > Hi Alexander, > > Thank you very much for the pointer. I downloaded "ago" version from this > link https://github.com/ago/openwrt. Both USB support and DWC_OTG now show > up in menuconfig as expected. "ago" is me :) > I was able to compile, build, load the firmware, and bring up the rt305x > board fine. However, when I plugged in a 3G USB modem, the console spitted > out usb descriptor error -32 (broken pipe??). Please see red messages > below. > > Any idea? Sorry, I forgot to tell: just reload the module. It doesn't work when the module is loaded for the first time after reboot. I.e you have to do like this: insmod dwc_otg.ko (done by autoload) rmmod dwc_otg insmod dwc_otg.ko I'm digging the problem but any help/testing is very much appreciated. > NET: Registered protocol family 24 > nf_conntrack version 0.5.0 (471 buckets, 1884 max) > dwc_otg: version 1.05 > Using DMA mode > dwc_otg dwc_otg.0: DWC OTG Controller > dwc_otg dwc_otg.0: new USB bus registered, assigned bus number 1 > dwc_otg dwc_otg.0: irq 26, io mem 0x101c > Init: Port Power? op_state=a_host > Init: Power Port (0) > hub 1-0:1.0: USB hub found > hub 1-0:1.0: 1 port detected > ++OTG Interrupt: Debounce Done++ > usbnet: Unknown symbol mii_ethtool_sset (err 0) > usbnet: Unknown symbol mii_link_ok (err 0) > usbnet: Unknown symbol mii_nway_restart (err 0) > usbnet: Unknown symbol mii_ethtool_gset (err 0) > usbcore: registered new interface driver usbserial > USB Serial support registered for generic > usb 1-1: new full speed USB device using dwc_otg and address 2 > usb 1-1: device descriptor read/64, error -32 > usb 1-1: device descriptor read/64, error -32 > usb 1-1: new full speed USB device using dwc_otg and address 3 > usb 1-1: device descriptor read/64, error -32 > usb 1-1: device descriptor read/64, error -32 > usb 1-1: new full speed USB device using dwc_otg and address 4 > usb 1-1: device not accepting address 4, error -32 > usb 1-1: new full speed USB device using dwc_otg and address 5 > usb 1-1: device not accepting address 5, error -32 > hub 1-0:1.0: unable to enumerate USB device on port 1 > usbcore: registered new interface driver usbserial_generic > usbserial: USB Serial Driver core > hso: drivers/net/usb/hso.c: Option Wireless > usbcore: registered new interface driver hso > USB Serial support registered for GSM modem (1-port) > usbcore: registered new interface driver option > option: v0.7.2:USB Driver for GSM modems > USB Serial support registered for Sierra USB modem > usbcore: registered new interface driver sierra > sierra: v.1.7.16:USB Driver for Sierra Wireless USB modems > ramips-wdt: timeout value 60 must be 0 < timeout < 33 > > > Cheers. > -Vincent > > On Fri, Feb 11, 2011 at 10:04 AM, Alexander Gordeev > wrote: > > > В Thu, 10 Feb 2011 11:18:39 +0800 > > HP Teoh пишет: > > > > > Hi Alexander, > > > > > > I have applied this usb patch and the dwc_otg patches to my trunk but I > > > still can't get the USB option to show up in make menuconfig -> Kernel > > > modules -> USB Support. > > > > Please try to checkout openwrt tree to a new directory and try again > > there. If it works then 'make clean' in the old clone would help > > probably. > > > > > On Tue, Feb 1, 2011 at 8:08 PM, Alexander Gordeev > >wrote: > > > > > > > Signed-off-by: Alexander Gordeev > > > > --- > > > > target/linux/ramips/files/arch/mips/ralink/Kconfig |3 +++ > > > > target/linux/ramips/rt305x/config-2.6.36 |3 --- > > > > 2 files changed, 3 insertions(+), 3 deletions(-) > > > > > > > > diff --git a/target/linux/ramips/files/arch/mips/ralink/Kconfig > > > > b/target/linux/ramips/files/arch/mips/ralink/Kconfig > > > > index c30dbe1..cf94798 100644 > > > > --- a/target/linux/ramips/files/arch/mips/ralink/Kconfig > > > > +++ b/target/linux/ramips/files/arch/mips/ralink/Kconfig > > > > @@ -47,6 +47,9 @@ config SOC_RT305X > > > >select SYS_SUPPORTS_LITTLE_ENDIAN > > > >select SYS_HAS_EARLY_PRINTK > > > >select MIPS_MACHINE > > > > +select USB_ARCH_HAS_EHCI > > > > +select USB_ARCH_HAS_HCD > > > > +select USB_ARCH_HAS_OHCI > > > > > > > > config RALINK_DEV_GPIO_BUTTONS > > > >def_bool n > > > > diff --git a/target/linux/ramips/rt305x/config-2.6.36 > > > > b/target/linux/ramips/rt305x/config-
Re: [OpenWrt-Devel] [PATCH 7/7] ramips: enable USB
В Thu, 10 Feb 2011 11:18:39 +0800 HP Teoh пишет: > Hi Alexander, > > I have applied this usb patch and the dwc_otg patches to my trunk but I > still can't get the USB option to show up in make menuconfig -> Kernel > modules -> USB Support. Please try to checkout openwrt tree to a new directory and try again there. If it works then 'make clean' in the old clone would help probably. > On Tue, Feb 1, 2011 at 8:08 PM, Alexander Gordeev > wrote: > > > Signed-off-by: Alexander Gordeev > > --- > > target/linux/ramips/files/arch/mips/ralink/Kconfig |3 +++ > > target/linux/ramips/rt305x/config-2.6.36 |3 --- > > 2 files changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/target/linux/ramips/files/arch/mips/ralink/Kconfig > > b/target/linux/ramips/files/arch/mips/ralink/Kconfig > > index c30dbe1..cf94798 100644 > > --- a/target/linux/ramips/files/arch/mips/ralink/Kconfig > > +++ b/target/linux/ramips/files/arch/mips/ralink/Kconfig > > @@ -47,6 +47,9 @@ config SOC_RT305X > >select SYS_SUPPORTS_LITTLE_ENDIAN > >select SYS_HAS_EARLY_PRINTK > >select MIPS_MACHINE > > +select USB_ARCH_HAS_EHCI > > +select USB_ARCH_HAS_HCD > > +select USB_ARCH_HAS_OHCI > > > > config RALINK_DEV_GPIO_BUTTONS > >def_bool n > > diff --git a/target/linux/ramips/rt305x/config-2.6.36 > > b/target/linux/ramips/rt305x/config-2.6.36 > > index 456a625..71db4b3 100644 > > --- a/target/linux/ramips/rt305x/config-2.6.36 > > +++ b/target/linux/ramips/rt305x/config-2.6.36 > > @@ -96,8 +96,5 @@ CONFIG_SYS_SUPPORTS_ARBIT_HZ=y > > CONFIG_SYS_SUPPORTS_LITTLE_ENDIAN=y > > # CONFIG_TINY_RCU is not set > > CONFIG_TREE_RCU=y > > -# CONFIG_USB_ARCH_HAS_EHCI is not set > > -# CONFIG_USB_ARCH_HAS_HCD is not set > > -# CONFIG_USB_ARCH_HAS_OHCI is not set > > CONFIG_USB_SUPPORT=y > > CONFIG_ZONE_DMA_FLAG=0 > > -- > > 1.7.2.3 -- Alexander signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/7] ramips: fix dir-300 mtd layout
Signed-off-by: Alexander Gordeev
---
.../arch/mips/ralink/rt305x/mach-dir-300-revb.c|2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
a/target/linux/ramips/files/arch/mips/ralink/rt305x/mach-dir-300-revb.c
b/target/linux/ramips/files/arch/mips/ralink/rt305x/mach-dir-300-revb.c
index d443e4f..7aed11d 100644
--- a/target/linux/ramips/files/arch/mips/ralink/rt305x/mach-dir-300-revb.c
+++ b/target/linux/ramips/files/arch/mips/ralink/rt305x/mach-dir-300-revb.c
@@ -51,7 +51,7 @@ static struct mtd_partition dir_300b_partitions[] = {
}, {
.name = "kernel",
.offset = 0x05,
- .size = 0x09,
+ .size = 0x0f,
}, {
.name = "rootfs",
.offset = 0x14,
--
1.7.2.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/7] generic: fix usb gadget header includes
Signed-off-by: Alexander Gordeev --- .../generic/patches-2.6.34/993-usb_gadget.patch| 20 .../generic/patches-2.6.36/993-usb_gadget.patch| 20 2 files changed, 40 insertions(+), 0 deletions(-) create mode 100644 target/linux/generic/patches-2.6.34/993-usb_gadget.patch create mode 100644 target/linux/generic/patches-2.6.36/993-usb_gadget.patch diff --git a/target/linux/generic/patches-2.6.34/993-usb_gadget.patch b/target/linux/generic/patches-2.6.34/993-usb_gadget.patch new file mode 100644 index 000..eedca54 --- /dev/null +++ b/target/linux/generic/patches-2.6.34/993-usb_gadget.patch @@ -0,0 +1,20 @@ +commit 3098baf9966950ac041ac3a8374cccb371eb3e4c +Author: Alexander Gordeev +Date: Sat Nov 27 05:32:06 2010 +0300 + +gadget.h: add missing include + +Signed-off-by: Alexander Gordeev + +diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h +index f4b7ca5..32743e3 100644 +--- a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h +@@ -15,6 +15,7 @@ + #ifndef __LINUX_USB_GADGET_H + #define __LINUX_USB_GADGET_H + ++#include + #include + + struct usb_ep; diff --git a/target/linux/generic/patches-2.6.36/993-usb_gadget.patch b/target/linux/generic/patches-2.6.36/993-usb_gadget.patch new file mode 100644 index 000..eedca54 --- /dev/null +++ b/target/linux/generic/patches-2.6.36/993-usb_gadget.patch @@ -0,0 +1,20 @@ +commit 3098baf9966950ac041ac3a8374cccb371eb3e4c +Author: Alexander Gordeev +Date: Sat Nov 27 05:32:06 2010 +0300 + +gadget.h: add missing include + +Signed-off-by: Alexander Gordeev + +diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h +index f4b7ca5..32743e3 100644 +--- a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h +@@ -15,6 +15,7 @@ + #ifndef __LINUX_USB_GADGET_H + #define __LINUX_USB_GADGET_H + ++#include + #include + + struct usb_ep; -- 1.7.2.3 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 4/7] ramips: add dwc_otg platform device
Signed-off-by: Alexander Gordeev
---
.../ramips/files/arch/mips/ralink/rt305x/devices.c | 26
.../ramips/files/arch/mips/ralink/rt305x/devices.h |1 +
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/target/linux/ramips/files/arch/mips/ralink/rt305x/devices.c
b/target/linux/ramips/files/arch/mips/ralink/rt305x/devices.c
index 7d41b07..1459a6f 100644
--- a/target/linux/ramips/files/arch/mips/ralink/rt305x/devices.c
+++ b/target/linux/ramips/files/arch/mips/ralink/rt305x/devices.c
@@ -217,3 +217,29 @@ void __init rt305x_register_wdt(void)
platform_device_register(&rt305x_wdt_device);
}
+
+static struct resource rt305x_usb_resources[] = {
+ {
+ .start = RT305X_OTG_BASE,
+ .end= RT305X_OTG_BASE + 0x3,
+ .flags = IORESOURCE_MEM,
+ }, {
+ .start = RT305X_INTC_IRQ_OTG,
+ .end= RT305X_INTC_IRQ_OTG,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device rt305x_usb_device = {
+ .name = "dwc_otg",
+ .resource = rt305x_usb_resources,
+ .num_resources = ARRAY_SIZE(rt305x_usb_resources),
+ .dev = {
+ .platform_data = NULL,
+ }
+};
+
+void __init rt305x_register_usb(void)
+{
+ platform_device_register(&rt305x_usb_device);
+}
diff --git a/target/linux/ramips/files/arch/mips/ralink/rt305x/devices.h
b/target/linux/ramips/files/arch/mips/ralink/rt305x/devices.h
index 352243c..6015dac 100644
--- a/target/linux/ramips/files/arch/mips/ralink/rt305x/devices.h
+++ b/target/linux/ramips/files/arch/mips/ralink/rt305x/devices.h
@@ -21,6 +21,7 @@ void rt305x_register_flash(unsigned int id, struct
physmap_flash_data *pdata);
void rt305x_register_ethernet(void);
void rt305x_register_wifi(void);
void rt305x_register_wdt(void);
+void rt305x_register_usb(void);
#endif /* __RT305X_DEVICES_H */
--
1.7.2.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 0/7] ramips usb support
Hi! This patchset adds full USB support to ramips target. I've used dwc_otg driver that was published on linuxppc-dev list. There were newer versions of this driver since then but it's still a work in progress and there were no major changes. I plan to migrate to the next available version of dwc_otg if all the discussed problems are fixed. I had to add several changes to this driver to make it work on ramips target. All changes to the driver will be available soon in my linux kernel git repository on github: https://github.com/ago/linux-2.6 The whole patchset is also available on github as well: https://github.com/ago/openwrt Alexander Gordeev (7): generic: fix usb gadget header includes mac80211: rt2800-lib doesn't depend on rt2x00-usb ramips: fix dir-300 mtd layout ramips: add dwc_otg platform device kernel: move nop-usb-xceiv to a separate package ramips: add usb support ramips: enable USB package/kernel/modules/usb.mk | 50 +- package/mac80211/Makefile |2 +- .../generic/patches-2.6.34/993-usb_gadget.patch| 20 + .../generic/patches-2.6.36/993-usb_gadget.patch| 20 + target/linux/ramips/files/arch/mips/ralink/Kconfig |3 + .../ramips/files/arch/mips/ralink/rt305x/devices.c | 26 + .../ramips/files/arch/mips/ralink/rt305x/devices.h |1 + .../arch/mips/ralink/rt305x/mach-dir-300-revb.c|2 +- .../linux/ramips/files/drivers/usb/dwc_otg/Kconfig | 96 + .../ramips/files/drivers/usb/dwc_otg/Makefile | 21 + .../files/drivers/usb/dwc_otg/dwc_otg_apmppc.c | 394 +++ .../ramips/files/drivers/usb/dwc_otg/dwc_otg_cil.c | 892 ++ .../ramips/files/drivers/usb/dwc_otg/dwc_otg_cil.h | 1177 +++ .../files/drivers/usb/dwc_otg/dwc_otg_cil_intr.c | 618 .../files/drivers/usb/dwc_otg/dwc_otg_driver.c | 393 +++ .../files/drivers/usb/dwc_otg/dwc_otg_driver.h | 78 + .../ramips/files/drivers/usb/dwc_otg/dwc_otg_hcd.c | 2402 ++ .../ramips/files/drivers/usb/dwc_otg/dwc_otg_hcd.h | 413 +++ .../files/drivers/usb/dwc_otg/dwc_otg_hcd_intr.c | 1465 + .../files/drivers/usb/dwc_otg/dwc_otg_hcd_queue.c | 697 + .../files/drivers/usb/dwc_otg/dwc_otg_param.c | 730 + .../ramips/files/drivers/usb/dwc_otg/dwc_otg_pcd.c | 1733 +++ .../ramips/files/drivers/usb/dwc_otg/dwc_otg_pcd.h | 137 + .../files/drivers/usb/dwc_otg/dwc_otg_pcd_intr.c | 2262 ++ .../files/drivers/usb/dwc_otg/dwc_otg_regs.h | 3265 target/linux/ramips/patches-2.6.36/105-usb.patch | 25 + target/linux/ramips/rt305x/config-2.6.36 |3 - 27 files changed, 16916 insertions(+), 9 deletions(-) create mode 100644 target/linux/generic/patches-2.6.34/993-usb_gadget.patch create mode 100644 target/linux/generic/patches-2.6.36/993-usb_gadget.patch create mode 100644 target/linux/ramips/files/drivers/usb/dwc_otg/Kconfig create mode 100644 target/linux/ramips/files/drivers/usb/dwc_otg/Makefile create mode 100644 target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_apmppc.c create mode 100644 target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_cil.c create mode 100644 target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_cil.h create mode 100644 target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_cil_intr.c create mode 100644 target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_driver.c create mode 100644 target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_driver.h create mode 100644 target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_hcd.c create mode 100644 target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_hcd.h create mode 100644 target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_hcd_intr.c create mode 100644 target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_hcd_queue.c create mode 100644 target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_param.c create mode 100644 target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_pcd.c create mode 100644 target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_pcd.h create mode 100644 target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_pcd_intr.c create mode 100644 target/linux/ramips/files/drivers/usb/dwc_otg/dwc_otg_regs.h create mode 100644 target/linux/ramips/patches-2.6.36/105-usb.patch -- 1.7.2.3 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 5/7] kernel: move nop-usb-xceiv to a separate package
Signed-off-by: Alexander Gordeev --- package/kernel/modules/usb.mk | 24 1 files changed, 20 insertions(+), 4 deletions(-) diff --git a/package/kernel/modules/usb.mk b/package/kernel/modules/usb.mk index 439d022..6d574ff 100644 --- a/package/kernel/modules/usb.mk +++ b/package/kernel/modules/usb.mk @@ -103,19 +103,35 @@ endef $(eval $(call KernelPackage,usb-ohci,1)) +define KernelPackage/nop-usb-xceiv + TITLE:=NOP USB Transceiver Driver + KCONFIG:=CONFIG_NOP_USB_XCEIV + FILES:=$(LINUX_DIR)/drivers/usb/otg/nop-usb-xceiv.ko + AUTOLOAD:=$(call AutoLoad,52,nop-usb-xceiv) + $(call AddDepends/usb) +endef + +define KernelPackage/nop-usb-xceiv/description + this driver is to be used by all the usb transceiver which are either + built-in with usb ip or which are autonomous and doesn't require any + phy programming such as ISP1x04 etc. +endef + +$(eval $(call KernelPackage,nop-usb-xceiv)) + + define KernelPackage/musb-hdrc TITLE:=Support for Mentor Graphics silicon dual role USB KCONFIG:= \ CONFIG_USB_MUSB_HDRC \ - CONFIG_NOP_USB_XCEIV \ CONFIG_USB_TUSB6010=y \ CONFIG_MUSB_PIO_ONLY=n \ CONFIG_USB_MUSB_OTG=y \ CONFIG_USB_MUSB_DEBUG=y DEPENDS:=@TARGET_omap24xx - FILES:=$(LINUX_DIR)/drivers/usb/otg/nop-usb-xceiv.ko $(LINUX_DIR)/drivers/usb/musb/musb_hdrc.ko - AUTOLOAD:=$(call AutoLoad,54,nop-usb-xceiv musb_hdrc) - $(call AddDepends/usb) + FILES:=$(LINUX_DIR)/drivers/usb/musb/musb_hdrc.ko + AUTOLOAD:=$(call AutoLoad,54,musb_hdrc) + $(call AddDepends/usb,+kmod-nop-usb-xceiv) endef define KernelPackage/musb-hdrc/description -- 1.7.2.3 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/7] mac80211: rt2800-lib doesn't depend on rt2x00-usb
Signed-off-by: Alexander Gordeev --- package/mac80211/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/package/mac80211/Makefile b/package/mac80211/Makefile index 39c56f2..854311f 100644 --- a/package/mac80211/Makefile +++ b/package/mac80211/Makefile @@ -272,7 +272,7 @@ endef define KernelPackage/rt2800-lib $(call KernelPackage/rt2x00/Default) - DEPENDS+= @(PCI_SUPPORT||USB_SUPPORT||TARGET_ramips) +kmod-rt2x00-lib +USB_SUPPORT:kmod-rt2x00-usb +TARGET_ramips:kmod-rt2x00-soc + DEPENDS+= @(PCI_SUPPORT||USB_SUPPORT||TARGET_ramips) +kmod-rt2x00-lib +TARGET_ramips:kmod-rt2x00-soc TITLE+= (rt2800 LIB) FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/rt2x00/rt2800lib.ko AUTOLOAD:=$(call AutoLoad,27,rt2800lib) -- 1.7.2.3 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 7/7] ramips: enable USB
Signed-off-by: Alexander Gordeev --- target/linux/ramips/files/arch/mips/ralink/Kconfig |3 +++ target/linux/ramips/rt305x/config-2.6.36 |3 --- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/target/linux/ramips/files/arch/mips/ralink/Kconfig b/target/linux/ramips/files/arch/mips/ralink/Kconfig index c30dbe1..cf94798 100644 --- a/target/linux/ramips/files/arch/mips/ralink/Kconfig +++ b/target/linux/ramips/files/arch/mips/ralink/Kconfig @@ -47,6 +47,9 @@ config SOC_RT305X select SYS_SUPPORTS_LITTLE_ENDIAN select SYS_HAS_EARLY_PRINTK select MIPS_MACHINE +select USB_ARCH_HAS_EHCI +select USB_ARCH_HAS_HCD +select USB_ARCH_HAS_OHCI config RALINK_DEV_GPIO_BUTTONS def_bool n diff --git a/target/linux/ramips/rt305x/config-2.6.36 b/target/linux/ramips/rt305x/config-2.6.36 index 456a625..71db4b3 100644 --- a/target/linux/ramips/rt305x/config-2.6.36 +++ b/target/linux/ramips/rt305x/config-2.6.36 @@ -96,8 +96,5 @@ CONFIG_SYS_SUPPORTS_ARBIT_HZ=y CONFIG_SYS_SUPPORTS_LITTLE_ENDIAN=y # CONFIG_TINY_RCU is not set CONFIG_TREE_RCU=y -# CONFIG_USB_ARCH_HAS_EHCI is not set -# CONFIG_USB_ARCH_HAS_HCD is not set -# CONFIG_USB_ARCH_HAS_OHCI is not set CONFIG_USB_SUPPORT=y CONFIG_ZONE_DMA_FLAG=0 -- 1.7.2.3 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] default stack size limit is too big
В Fri, 28 Jan 2011 13:47:18 +0100 Felix Fietkau пишет: > On 2011-01-28 1:28 PM, Alexander Gordeev wrote: > > Hi! > > > > I have a device with only 16MB of memory and I want to run threaded > > applications on it. The size of allocated stack space in uClibc's > > implementation of pthread_create equals to the stack size limit as > > returned by ulimit -s (or the default for the current architecture if > > the limit is set to 'unlimited' which is 2MB for MIPS). The problem is > > that the limit on my 16MB box is somehow set to 8MB for all processes > > which is a half of available RAM so the allocation fails. If I enable > > aggressive overcommit (echo 1 > /proc/sys/vm/overcommit_memory) or > > lower the limit (ulimit -s 2048 or ulimit -s unlimited) then everything > > works like a charm. > > > > Where is the 8MB stack size limit set? > > > > BTW I use openwrt trunk, uClibc 0.9.32 with nptl, everything else is > > default. > Please try copying this patch to toolchain/uClibc/patches-0.9.32 - > http://nbd.name/190-nptl_use_arch_default_stack_limit.patch > and see if rebuilding uclibc with it fixes the problem. > > The issue that I found is that if getrlimit returns a valid value for > the stack limit, it will be used as a default even if the architecture > specific default is lower. Yes, this patch fixes my problem, thank you very much! -- Alexander signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] default stack size limit is too big
Hi! I have a device with only 16MB of memory and I want to run threaded applications on it. The size of allocated stack space in uClibc's implementation of pthread_create equals to the stack size limit as returned by ulimit -s (or the default for the current architecture if the limit is set to 'unlimited' which is 2MB for MIPS). The problem is that the limit on my 16MB box is somehow set to 8MB for all processes which is a half of available RAM so the allocation fails. If I enable aggressive overcommit (echo 1 > /proc/sys/vm/overcommit_memory) or lower the limit (ulimit -s 2048 or ulimit -s unlimited) then everything works like a charm. Where is the 8MB stack size limit set? BTW I use openwrt trunk, uClibc 0.9.32 with nptl, everything else is default. -- Alexander signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
