[OpenWrt-Devel] Q: mac80211: defailt distance-settings 0
i seems that '/lib/netifd/wireless/mac80211.sh' sets the default distance to '0' if not defined via uci. what does that mean? dynamic ack or not? because 0 seems to be a valid value: root@box:~ iw phy phy0 set distance Usage: iw [options] phy phyname set distance auto|distance Enable ACK timeout estimation algorithm (dynack) or set appropriate coverage class for given link distance in meters. To disable dynack set valid value for coverage class. Valid values: 0 - 114750 bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 00/10] lantiq - vgv7519 - multiple dts fix and make minipci card visible
can we have the same for BB please ? On 06/10/2014 17:10, Eddi De Pieri wrote: Hi maintainers, As requested I'm trying to send my patch to the mail list. Whith these patch I'm able to: 1. get rt2800pci driver to probe the wifi board. 2. leds connected to stp to work again (some changes into openwrt broken them) 3. gphy leds working Regards Eddi De Pieri (10): lantiq: fix some alt function on pinctrl-xway lantiq - vgv7519: fix gphy led configuration (this set correct alt function to gpio and let peripherials on pci bus to comes up) lantiq - vgv7519: we don't have dual minipci-card so we don't need gnt1-req1 for pci handling lantiq - vgv7519: we don't have pcie bus so we don't need the reset device tree for this board lantiq - vgv7519: remove exin definition copied from dev-board dts lantiq - vgv7519: add pci-rst entry into dts lantiq - vgv7519: fix open-drain configuration for stp lantiq - vgv7519: remove spi_cs4, since the board use this line for something else lantiq - vgv7519: enable pci bus lantiq - vgv7519: load rt5362 eeprom from bootloader param patition .../etc/hotplug.d/firmware/10-rt2x00-eeprom|2 +- target/linux/lantiq/dts/VGV7519.dtsi | 48 +++- target/linux/lantiq/dts/VGV7519BRN.dts |6 +++ target/linux/lantiq/dts/VGV7519NOR.dts |6 +++ .../patches-3.14/0150-lantiq-pinctrl-xway.patch| 15 ++ target/linux/lantiq/xrx200/config-3.14 |2 +- 6 files changed, 55 insertions(+), 24 deletions(-) create mode 100644 target/linux/lantiq/patches-3.14/0150-lantiq-pinctrl-xway.patch -- 1.7.10.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] kernel: add missing symbols for 3.14
spotted by buildbot brcm2708: http://buildbot.openwrt.org:8010/builders/brcm2708/ Signed-off-by: Dirk Neukirchen dirkneukirc...@web.de --- target/linux/generic/config-3.14 | 3 +++ 1 file changed, 3 insertions(+) diff --git a/target/linux/generic/config-3.14 b/target/linux/generic/config-3.14 index 2501f72..830efff 100644 --- a/target/linux/generic/config-3.14 +++ b/target/linux/generic/config-3.14 @@ -307,12 +307,15 @@ CONFIG_ATM_CLIP_NO_ICMP=y # CONFIG_B44 is not set # CONFIG_B53 is not set # CONFIG_B53_SPI_DRIVER is not set +# CONFIG_BACKLIGHT_BD6107 is not set # CONFIG_BACKLIGHT_GPIO is not set # CONFIG_BACKLIGHT_LCD_SUPPORT is not set # CONFIG_BACKLIGHT_LM3630 is not set # CONFIG_BACKLIGHT_LM3630A is not set # CONFIG_BACKLIGHT_LM3639 is not set # CONFIG_BACKLIGHT_LP855X is not set +# CONFIG_BACKLIGHT_LV5207LP is not set +# CONFIG_BACKLIGHT_PANDORA is not set # CONFIG_BACKTRACE_SELF_TEST is not set CONFIG_BASE_FULL=y CONFIG_BASE_SMALL=0 -- 2.1.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] BB SDKs are too lean (no libffi, etc.)
Hi Paul, the trick is to add the OpenWrt source as package feed, this way you gain access to libffi and any other core packages: $ wget https://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/generic/OpenWrt-SDK-ar71xx-for-linux-x86_64-gcc-4.8-linaro_uClibc-0.9.33.2.tar.bz2 [...] $ tar -xjf OpenWrt-SDK-ar71xx-for-linux-x86_64-gcc-4.8-linaro_uClibc-0.9.33.2.tar.bz2 $ cd OpenWrt-SDK-ar71xx-for-linux-x86_64-gcc-4.8-linaro_uClibc-0.9.33.2/ $ echo src-git base git://git.openwrt.org/14.07/openwrt.git feeds.conf.default $ ./scripts/feeds update [...] $ ./scripts/feeds install -d m libffi [...] $ make package/libffi/compile $ ls -l bin/ar71xx/packages/*/ bin/ar71xx/packages/base/: total 568 -rw-r--r-- 1 jow jow 9340 Oct 7 10:49 ldconfig_0.9.33.2-1_ar71xx.ipk -rw-r--r-- 1 jow jow 5375 Oct 7 10:49 ldd_0.9.33.2-1_ar71xx.ipk -rw-r--r-- 1 jow jow 224825 Oct 7 10:49 libc_0.9.33.2-1_ar71xx.ipk -rw-r--r-- 1 jow jow 32424 Oct 7 10:49 libgcc_4.8-linaro-1_ar71xx.ipk -rw-r--r-- 1 jow jow 31823 Oct 7 10:49 libpthread_0.9.33.2-1_ar71xx.ipk -rw-r--r-- 1 jow jow 5578 Oct 7 10:49 librt_0.9.33.2-1_ar71xx.ipk -rw-r--r-- 1 jow jow 256572 Oct 7 10:49 libstdcpp_4.8-linaro-1_ar71xx.ipk -rw-r--r-- 1 jow jow755 Oct 7 10:49 libthread-db_0.9.33.2-1_ar71xx.ipk bin/ar71xx/packages/packages/: total 8 -rw-r--r-- 1 jow jow 6161 Oct 7 10:49 libffi_3.0.13-1_ar71xx.ipk ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [luci] [DISCUSSION] How to support LuCI applications not in OpenWrt packages repository
On Fri, Oct 3, 2014 at 11:32 AM, Christian Schoenebeck christian.schoeneb...@gmail.com wrote: Hi, we got a new ticket inside OpenWrt Ticket #18018 with problems inside LuCI app. This is normally not an OpenWrt ticket it's a LuCI ticket, but the user don't know. If the user try to post the ticket at LuCI trac it takes weeks before the ticket is reported by LuciTrac to the mailing lists. So for a me as an external developer there is no chance to help quick. LuCi trac is also no good choice to send patches or possibly new functionality. LuCI trac has problems to accept file attachments when creating a new ticket. LuCI trac gives no chance to correct/edit a ticket or append a comment if you just create it. From my point of view LuCi trac is more then awful including used CHAPTCHA. Sending patches or new functionality to luci mailing list is also not a choice because there is no guarantee that the code is implemented short term. My idea is to move code of LuCI applications like tinyproxy, samba, hd-idle, ddns-scripts, . to OpenWrt/packages as samba/samba-luci, tinyproxy/tinyproxy-luci or ddns-scripts/ddns-scripts-luci. The mwan3 package already doing this. As there is no objection, would it make sense to move forward with that? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [luci] [DISCUSSION] How to support LuCI applications not in OpenWrt packages repository
Hi. In principle I have no objections but we need to figure out a way on how to deal with translation files. If stuff is split out of the LuCI repo you have to take of that yourself. ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Q: mac80211: defailt distance-settings 0
On 2014-10-07 08:15, Bastian Bittorf wrote: i seems that '/lib/netifd/wireless/mac80211.sh' sets the default distance to '0' if not defined via uci. what does that mean? dynamic ack or not? because 0 seems to be a valid value: 0 does not imply dynamic ACK, it is simply the minimum value. Enabling dynack by default would be a bad idea. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] cns3xxx: fix shared PCI interrupt mapping
On 2014-10-06 21:23, Pushpal Sidhu wrote: This patch originally failed to combine INTA/B/C/D onto a single ARM CPU interrupt. Instead, it mapped INTA/B/C and excluded D. This patch corrects the issue by mapping all four interrupts to the single ARM CPU interrupt. The original intent of the patch still holds as the newer PCB take advantage of isolated interrupts. This fix only applies to older PCB's that do not route INTA/B/C/D to unique external ARM CPU interrupts. Signed-off-by: Pushpal Sidhu psi...@gateworks.com Applied in r42830, thanks. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 00/10] lantiq - vgv7519 - multiple dts fix and make minipci card visible
On Tue, Oct 7, 2014 at 9:37 AM, John Crispin blo...@openwrt.org wrote: can we have the same for BB please ? Sure, but later Eddi ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Q: lantiq pcie and device-tree
Hi, By comparing the gpio register on original firmware and openwrt I found that Openwrt have gpio 38 as output, while the original firmware leave this as gpio input even if i don't configured it as pcie-reset on dts. I think that this may damage when porting openwrt on new router board. There is a explaination on the fact that ifxmips-pcie driver don't use device-tree yet? Regards Eddi ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [base-files] shell-scripting: fix wrong usage of '==' operator
[base-files] shell-scripting: fix wrong usage of '==' operator
normally the '==' is used for invoking a regex parser and is a bashism.
all of the fixes just want to compare a string. the used busybox-ash
will silently ignore this mistake, but make it portable/clean at least.
this patch does not change the behavior/logic of the scripts.
Signed-off-by: Bastian Bittorf bitt...@bluebottle.com
---
package/base-files/files/lib/functions/uci-defaults-new.sh |2 +-
package/base-files/files/lib/functions/uci-defaults.sh |2 +-
package/base-files/files/sbin/led.sh |6 +++---
package/base-files/files/sbin/wifi |2 +-
package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh |2 +-
package/network/config/qos-scripts/files/usr/bin/qos-stat |4 ++--
package/network/services/dropbear/files/dropbear.init |2 +-
package/network/services/hostapd/files/wpa_supplicant.sh |2 +-
package/network/services/openvpn/files/openvpn.init|2 +-
package/network/services/relayd/files/relay.init |2 +-
package/system/fstools/files/snapshot |6 +++---
package/system/procd/files/nand.sh |4 ++--
package/system/procd/files/procd.sh|2 +-
scripts/flashing/flash.sh |6 +++---
.../base-files/etc/uci-defaults/03_network-switchX-migration |2 +-
.../linux/ar71xx/base-files/etc/uci-defaults/04_led_migration |4 ++--
target/linux/brcm2708/image/gen_rpi_sdcard_img.sh |2 +-
.../base-files/lib/preinit/15_set_preinit_interface_brcm |2 +-
.../ixp4xx/base-files/lib/preinit/05_set_ether_mac_ixp4xx |8
target/linux/ramips/base-files/etc/hotplug.d/usb/10-motion |2 +-
.../linux/ramips/base-files/lib/preinit/04_handle_checksumming |2 +-
target/linux/sunxi/image/gen_sunxi_sdcard_img.sh |2 +-
target/linux/x86_64/image/gen_image_generic.sh |2 +-
23 files changed, 35 insertions(+), 35 deletions(-)
diff --git a/package/base-files/files/lib/functions/uci-defaults-new.sh
b/package/base-files/files/lib/functions/uci-defaults-new.sh
index ba954de..0751744 100755
--- a/package/base-files/files/lib/functions/uci-defaults-new.sh
+++ b/package/base-files/files/lib/functions/uci-defaults-new.sh
@@ -34,7 +34,7 @@ _ucidef_set_interface() {
json_select_object $name
json_add_string ifname ${iface%%.*}
- [ $iface == ${iface%%.*} ] || json_add_boolean create_vlan 1
+ [ $iface = ${iface%%.*} ] || json_add_boolean create_vlan 1
json_select ..
}
diff --git a/package/base-files/files/lib/functions/uci-defaults.sh
b/package/base-files/files/lib/functions/uci-defaults.sh
index e90090c..8a9a0ff 100644
--- a/package/base-files/files/lib/functions/uci-defaults.sh
+++ b/package/base-files/files/lib/functions/uci-defaults.sh
@@ -140,7 +140,7 @@ EOF
ucidef_commit_leds()
{
- [ $UCIDEF_LEDS_CHANGED == 1 ] uci commit system
+ [ $UCIDEF_LEDS_CHANGED = 1 ] uci commit system
}
ucidef_set_interface_loopback() {
diff --git a/package/base-files/files/sbin/led.sh
b/package/base-files/files/sbin/led.sh
index d67a0f5..d750f06 100755
--- a/package/base-files/files/sbin/led.sh
+++ b/package/base-files/files/sbin/led.sh
@@ -9,15 +9,15 @@ do_led() {
local sysfs
config_get name $1 name
config_get sysfs $1 sysfs
- [ $name == $NAME -o $sysfs = $NAME -a -e
/sys/class/leds/${sysfs} ] {
- [ $ACTION == set ]
+ [ $name = $NAME -o $sysfs = $NAME -a -e
/sys/class/leds/${sysfs} ] {
+ [ $ACTION = set ]
echo 1 /sys/class/leds/${sysfs}/brightness \
|| echo 0 /sys/class/leds/${sysfs}/brightness
exit 0
}
}
-[ $1 == clear -o $1 == set ]
+[ $1 = clear -o $1 = set ]
[ -n $2 ] {
config_load system
config_foreach do_led
diff --git a/package/base-files/files/sbin/wifi
b/package/base-files/files/sbin/wifi
index 051bc89..2476414 100755
--- a/package/base-files/files/sbin/wifi
+++ b/package/base-files/files/sbin/wifi
@@ -108,7 +108,7 @@ wifi_fixup_hwmode() {
_wifi_updown() {
for device in ${2:-$DEVICES}; do (
config_get disabled $device disabled
- [ 1 == $disabled ] {
+ [ $disabled = 1 ] {
echo '$device' is disabled
set disable
}
diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
index e6241de..918955a 100644
--- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
+++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
@@ -476,7 +476,7 @@
Re: [OpenWrt-Devel] [PATCH procd] Add ctrlaltdel handler to procd
Hello John,
I saw you had reworked my ctrl-alt-del patch for procd. Ok, but
unfortunately, it does not work for me.
What happens; when I press ctrl-alt-del on the unit, I get an
attempting to kill init panic.
This happens because the procd process exits. The kernel does not like
its init process dying.
If I look in procd.c, I see:
uloop_run();
uloop_done();
if (getpid() == 1) {
procd_shutdown(RB_AUTOBOOT);
}
procd_shutdown( ) is called, I see this on the console. But it
indirectly fires off a runqueue which should be handled from the
uloop_run( ) call. This takes care of running the shutdown scripts. But
the uloop has already been cleaned up by uloop_done( ), because the
uloop_run( ) was interrupted by the SIGINT.
Thus this runqueue is never handled. Because of this, its rcdone( ) is
never called (inittab.c), which should invoke procd_state_next( ), which
then moves procd into killing the processes and calling the reboot( )
system call.
It is important that procd does not exit before the reboot( ) system
call is called thus remaining in the uloop_run( ) and letting the loop
run its course, but without grabbing SIGINT back from libubox/uloop, I
would have no idea how to fix this.
My fix, by adding something to libubox to unhook SIGINT so the
application can catch it was not pretty, but it did solve this problem.
Another problem would be adding a process which grabs SIGINT back from
uloop( ) but this sounds a bit hackish to me.
Any suggestions?
I have finished the /proc/cmdline patch, but I'm hanging on to it as
testing my terminal fix is a tad difficult if I can't get the reboot
working properly.
Michel Stam
-Original Message-
From: Michel Stam [mailto:m.s...@fugro.nl]
Sent: Thursday, October 02, 2014 14:51 PM
To: openwrt-devel@lists.openwrt.org
Cc: Stam, Michel [FINT]
Subject: [PATCH procd] Add ctrlaltdel handler to procd
Procd, up until now, did not support the ctrlaltdel handler. Thus, the
system would immediately reboot upon the three-finger salute, and no
shutdown scripts would be run. This patch adds the handler for the
/etc/inittab entry, so that /sbin/reboot can be run and in turn the
shutdown scripts can be invoked.
Signed-off-by: Michel Stam m.s...@fugro.nl
---
procd.c | 1 +
signal.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/procd.c b/procd.c
index ad80284..6ec7cd0 100644
--- a/procd.c
+++ b/procd.c
@@ -62,6 +62,7 @@ int main(int argc, char **argv)
}
}
uloop_init();
+ uloop_release_sigint();
procd_signal();
trigger_init();
if (getpid() != 1)
diff --git a/signal.c b/signal.c
index 74cabcb..6c00fd9 100644
--- a/signal.c
+++ b/signal.c
@@ -36,6 +36,7 @@ static void signal_shutdown(int signal, siginfo_t
*siginfo, void *data)
char *msg = NULL;
switch(signal) {
+ case SIGINT:
case SIGTERM:
event = RB_AUTOBOOT;
msg = reboot;
@@ -91,4 +92,6 @@ void procd_signal(void)
sigaction(SIGHUP, sa_dummy, NULL);
sigaction(SIGKILL, sa_dummy, NULL);
sigaction(SIGSTOP, sa_dummy, NULL);
+ sigaction(SIGINT, sa_shutdown, NULL);
+ reboot(RB_DISABLE_CAD);
}
--
1.7.12.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Q: mac80211: default distance-settings 0
* Felix Fietkau n...@openwrt.org [07.10.2014 13:40]: On 2014-10-07 08:15, Bastian Bittorf wrote: because 0 seems to be a valid value: 0 does not imply dynamic ACK, it is simply the minimum value. Enabling dynack by default would be a bad idea. what does 0 mean? the wiki says: 0 meters away, so a short ack-timeout is used, or is '0' something special, eg. driver default? i tested a p2p/longshot here, where both stations are 350m away, but invoking on both sides: iw phy phy0 set distance 350 shows, that the link gets really worse, also with 500 or 2000. can't it be changed during runtime? bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH procd] Add ctrlaltdel handler to procd
I just had a thought-
Is it possible to move grabbing the SIGINT from uloop_run( ) to
uloop_init( ), with the possibility to execute a
uloop_call_this_to_end_loop() function which sets the uloop_cancelled
variable? (this could then be called from a signal handler without
exposing the uloop_cancelled variable).
The signal handler can be hooked by default by uloop to emulate existing
behaviour if that is so desired, but by taking things out of uloop_run(
) it is possible to grab back SIGINT in a nice way.
Let me know, I can rework the patches to get this to work again, but I
think its wiser to discuss this first, then implement it.
Kind regards,
Michel Stam
-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
Behalf Of Stam, Michel [FINT]
Sent: Tuesday, October 07, 2014 17:08 PM
To: openwrt-devel@lists.openwrt.org; John Crispin
Subject: Re: [OpenWrt-Devel] [PATCH procd] Add ctrlaltdel handler to
procd
Hello John,
I saw you had reworked my ctrl-alt-del patch for procd. Ok, but
unfortunately, it does not work for me.
What happens; when I press ctrl-alt-del on the unit, I get an
attempting to kill init panic.
This happens because the procd process exits. The kernel does not like
its init process dying.
If I look in procd.c, I see:
uloop_run();
uloop_done();
if (getpid() == 1) {
procd_shutdown(RB_AUTOBOOT);
}
procd_shutdown( ) is called, I see this on the console. But it
indirectly fires off a runqueue which should be handled from the
uloop_run( ) call. This takes care of running the shutdown scripts. But
the uloop has already been cleaned up by uloop_done( ), because the
uloop_run( ) was interrupted by the SIGINT.
Thus this runqueue is never handled. Because of this, its rcdone( ) is
never called (inittab.c), which should invoke procd_state_next( ), which
then moves procd into killing the processes and calling the reboot( )
system call.
It is important that procd does not exit before the reboot( ) system
call is called thus remaining in the uloop_run( ) and letting the loop
run its course, but without grabbing SIGINT back from libubox/uloop, I
would have no idea how to fix this.
My fix, by adding something to libubox to unhook SIGINT so the
application can catch it was not pretty, but it did solve this problem.
Another problem would be adding a process which grabs SIGINT back from
uloop( ) but this sounds a bit hackish to me.
Any suggestions?
I have finished the /proc/cmdline patch, but I'm hanging on to it as
testing my terminal fix is a tad difficult if I can't get the reboot
working properly.
Michel Stam
-Original Message-
From: Michel Stam [mailto:m.s...@fugro.nl]
Sent: Thursday, October 02, 2014 14:51 PM
To: openwrt-devel@lists.openwrt.org
Cc: Stam, Michel [FINT]
Subject: [PATCH procd] Add ctrlaltdel handler to procd
Procd, up until now, did not support the ctrlaltdel handler. Thus, the
system would immediately reboot upon the three-finger salute, and no
shutdown scripts would be run. This patch adds the handler for the
/etc/inittab entry, so that /sbin/reboot can be run and in turn the
shutdown scripts can be invoked.
Signed-off-by: Michel Stam m.s...@fugro.nl
---
procd.c | 1 +
signal.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/procd.c b/procd.c
index ad80284..6ec7cd0 100644
--- a/procd.c
+++ b/procd.c
@@ -62,6 +62,7 @@ int main(int argc, char **argv)
}
}
uloop_init();
+ uloop_release_sigint();
procd_signal();
trigger_init();
if (getpid() != 1)
diff --git a/signal.c b/signal.c
index 74cabcb..6c00fd9 100644
--- a/signal.c
+++ b/signal.c
@@ -36,6 +36,7 @@ static void signal_shutdown(int signal, siginfo_t
*siginfo, void *data)
char *msg = NULL;
switch(signal) {
+ case SIGINT:
case SIGTERM:
event = RB_AUTOBOOT;
msg = reboot;
@@ -91,4 +92,6 @@ void procd_signal(void)
sigaction(SIGHUP, sa_dummy, NULL);
sigaction(SIGKILL, sa_dummy, NULL);
sigaction(SIGSTOP, sa_dummy, NULL);
+ sigaction(SIGINT, sa_shutdown, NULL);
+ reboot(RB_DISABLE_CAD);
}
--
1.7.12.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Openwrt x86_64 grub2 fallback feature
Hello.
I was trying to bring up GRUB fallback feature on x86_64 based OpenWRT
build.
I used this article as a reference.
http://www.linuxscrew.com/2012/04/24/grub-fallback-boot-good-kernel-if-new-one-crashes/
It's for Fedora, but I hope, that I can do something similar for openwrt.
Here's my config:
serial --unit=0 --speed=38400 --word=8 --parity=no --stop=1
terminal_input console serial; terminal_output console serial
set default=saved
set timeout=5
set root='(hd0,msdos1)'
set fallback=0 1
menuentry OpenWrt {
linux /boot/vmlinuz root=/dev/sda2 rootfstype=ext4 rootwait
console=tty0 console=ttyS0,38400n8 noinitrd
savedefault fallback
}
menuentry OpenWrt-backup {
linux /boot/vmlinuz-backup root=/dev/sda3 rootfstype=ext4 rootwait
console=tty0 console=ttyS0,38400n8 noinitrd
savedefault fallback
}
menuentry OpenWrt (failsafe) {
linux /boot/vmlinuz failsafe=true root=/dev/sda2 rootfstype=ext4
rootwait console=tty0 console=ttyS0,38400n8 noinitrd
}
But, when I try to boot openwrt with this config I get message, that
command is not recognized.
Booting `OpenWrt'
error: can't find command `savedefault'.
Press any key to continue...
Can I reconfigure a grub somehow in order to have this feature?
Thanks,
Alex
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Q: mac80211: defailt distance-settings 0 (Felix Fietkau)
Message: 1 Date: Tue, 07 Oct 2014 12:35:25 +0200 From: Felix Fietkau n...@openwrt.org To: mailinglist openwrt-devel@lists.openwrt.org Subject: Re: [OpenWrt-Devel] Q: mac80211: defailt distance-settings 0 Message-ID: 5433c1ed.5050...@openwrt.org Content-Type: text/plain; charset=windows-1252 On 2014-10-07 08:15, Bastian Bittorf wrote: i seems that '/lib/netifd/wireless/mac80211.sh' sets the default distance to '0' if not defined via uci. what does that mean? dynamic ack or not? because 0 seems to be a valid value: 0 does not imply dynamic ACK, it is simply the minimum value. Enabling dynack by default would be a bad idea. - Felix Felix- Thanks for the clarification; I was under the same impression as Bastian. Which brings up three follow-up questions: 1. How DO you turn dynack on? 2. When was dynack first added to ath9k and to OpenWRT? (I.e. what's the earliest version of OpenWRT in which it can be used?) 3.) Is 0 the right default for distance? Might 100 or 1000 be better values? (I'm using OpenWRT for outdoor WiFi in the U.S. with 600 mw access points, so I may have a slightly warped sense of what's right here...) In my experience, the default seems to work OK out to over 2 km. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [luci] [DISCUSSION] How to support LuCI applications not in OpenWrt packages repository
Am 07.10.2014 um 11:49 schrieb Jo-Philipp Wich: Hi. In principle I have no objections but we need to figure out a way on how to deal with translation files. If stuff is split out of the LuCI repo you have to take of that yourself. ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel Hi, language support could be a problem, but what I tested for my ddns-scripts-luci (not yet published) you need three files from LuCI system files located inside ./build directory. - i18n-scan.pl to scan .lua and .js files for strings that need to be translated (creating the .pot file). - i18n-po2lmo.pl together with - po2lmo (binary) to scan the po/[lang] directories for creation of the final [app].[lang].lmo files. Both .pl files need some modifications to reflect the OpenWrt build structure. This should not be a real show-stopper. If the .pot template exists, everybody can edit the .po file easily and publish it via git. If a new .pot template is create due to code changes you can verify the .po against .pot and only need to update some translations. The other option is to find a way to make the LuCI distribution system more public like OpenWrt base and packages system. What I mean, if I push an update to OpenWrt, it takes max 24 hours until merged to trunk. My offer of a patch that rebuild current luci-app-ddns is pending at luci@lists... since 21. Sep. I also opened up a ticket at TRAC not knowing where it is hanging around I wrote a fix to OpenWrt TRAC Ticket #18018 reported on 03.Oct. which fixes problems in current 14.07 RELEASE and trunk. I resend on 04.Oct. - today is the 07.Oct. nothing happen. But with direct access, 2 fixes were merged into LuCI trunk. Sorry I'm German and there might be some wrong words inside my English. I want to work together with all of you to find a way to support our users and continue to build a more than brilliant system. Christian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Q: mac80211: default distance-settings 0
Message: 1 Date: Tue, 7 Oct 2014 17:17:40 +0200 From: Bastian Bittorf bitt...@bluebottle.com To: mailinglist openwrt-devel@lists.openwrt.org Subject: Re: [OpenWrt-Devel] Q: mac80211: default distance-settings 0 Message-ID: 20141007151740.gj29...@medion.lan Content-Type: text/plain; charset=us-ascii * Felix Fietkau n...@openwrt.org [07.10.2014 13:40]: On 2014-10-07 08:15, Bastian Bittorf wrote: because 0 seems to be a valid value: 0 does not imply dynamic ACK, it is simply the minimum value. Enabling dynack by default would be a bad idea. what does 0 mean? the wiki says: 0 meters away, so a short ack-timeout is used, or is '0' something special, eg. driver default? i tested a p2p/longshot here, where both stations are 350m away, but invoking on both sides: iw phy phy0 set distance 350 shows, that the link gets really worse, also with 500 or 2000. can't it be changed during runtime? bye, bastian -- Bastian- I was doing some tests last week using an access point running a CC trunk build. I remembered that the right value was supposed to be the actual distance*2 (essentially, counting out and back distance). My test link was at about 8 km. I tried a number of values (on both AP and client) - distance=15000, 1, and then just backed it off by 1000 incrementally - and the throughput (measured with iperf) got better as I went down in distance. The optimal throughput was at distance=5000, where it was about 5 Mbps. However, when I set it at distance=4000, suddenly throughput went to less than 200 Kbps. Real world observations, FWIW... -Bill ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [luci] [DISCUSSION] How to support LuCI applications not in OpenWrt packages repository
On Tue, 2014-10-07 at 19:24 +0200, Jo-Philipp Wich wrote: Hi. I think about abandoning the LuCI Trac entirely and only accept patches sent to the mailinglist, I lack time and resources to keep it running and spam-free. So please resend the patches to the LuCI list in case you haven't done already and I'll try to get them merged until tomorrow. Wouldn't it be more efficient if luci was on github too? (even as a separate repository but with multiple committers) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Default dhcp (client) hostname is unset - Luci implies $(hostname)
[BB 14.07] In the Luci section for Interface / General Setup, the is a parameter Hostname to send when requesting DHCP. That input field has a ghost value of $HOSTNAME (meaning to me that its default value is $HOSTNAME). However, entering the $HOSTNAME in the field changes the behavior. I can see udhcpc being called with -H $host if I give a value, and no -H if left blank. It appears from command-line options that -H (or newer -x hostname:$HOST) causes the DHCP Hostname option to be sent, but it is not sent otherwise. So either: 1) The dhcp hostname option should be blank to indicate no default value (maintain current behavior) 2) When udhcpc is invoked, it should pass -H $(hostname) in case of default (make backend behave as Luci implies) IMO: I find it nice that many hosts pass their hostname automatically, so that the DHCP active lease list is useful, versus a lot of ? entries and ethernet addresses. So, I would vote for 2. Opinions? Where would this bug get posted? (wiki.openwrt.org is down, so I cannot check the wiki) -- -Justin justinval...@gmail.com smime.p7s Description: S/MIME Cryptographic Signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] desperately seeking info on this weird MT7620A/MT7610EN dev board
i apologize for repeating some of what i asked on the users list recently, but i'm rapidly running out of ideas and would be massively grateful for any assistance. just yesterday, i was handed an obvious development board, based on the MT7620A processor, and MT7610EN radio chip, and was asked to look into what it would take to get openwrt running on it. first thing i did was plug it in, connect to the console port and, sure enough, it booted to a version of openwrt -- PandoraBox -- which would appear to be a chinese version of openwrt. i connected the board via ethernet and browsed and, sure enough, i was shown the top-level luci admin page but, again, all the captions were in chinese (that was easy enough to fix). so, that the board can support openwrt seems fairly obvious, but here's where i'm having trouble. there is absolutely no identification on the board as to the manufacturer and, weirdly, no one who supplied the board knows where it came from, so i have no system reference manual. (the board comes with a full-size SD card slot which would be great to boot off of, but i have no idea what format the card requires.) so, first, i can see with openwrt trunk that MT7620A support is pretty solid -- that's the selection i made in menuconfig. but what about support for the MT7610E? i can see that, when i build, one of the squashfs images is for a mt7620a_mt7610e combination, so that makes me optimistic. and i can also see the MT7620a_MT7610e.dts device tree source file, so this makes me conclude i should be safe here. next issue is that the radio chip clearly shows, not MT7610E, but MT7610EN. i can find little online about this variation -- is it compatible with the MT7610E? finally, given that this board looks like *someone's* dev board, would anyone know where it might have come from? there's no manufacturer name on it anywhere. in the ramips dts file MT7620a.dts, i can see a reference to a Ralink MT7620a + MT7610e evaluation board. might that be it? i'd post a pic but i signed an NDA, although since no one has any idea where the board came from, i'm not sure what i'd be disclosing by posting a pic. i'm open to any information i can get, particularly support for that MT7610EN radio chip. thanks muchly. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] cns3xxx: Adopt irq_domain support for cns3xxx gpio driver
Have gpio driver adopt irqdomain support so that there are
non-overlapping allocations of irq numbers mapped to gpio's.
Signed-off-by: Pushpal Sidhu psi...@gateworks.com
---
.../cns3xxx/files/arch/arm/mach-cns3xxx/gpio.c | 30 +-
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/target/linux/cns3xxx/files/arch/arm/mach-cns3xxx/gpio.c
b/target/linux/cns3xxx/files/arch/arm/mach-cns3xxx/gpio.c
index 35434f8..b6e4061 100644
--- a/target/linux/cns3xxx/files/arch/arm/mach-cns3xxx/gpio.c
+++ b/target/linux/cns3xxx/files/arch/arm/mach-cns3xxx/gpio.c
@@ -15,6 +15,7 @@
#include linux/io.h
#include linux/gpio.h
#include linux/irq.h
+#include linux/irqdomain.h
#include asm/mach/irq.h
@@ -45,9 +46,9 @@
struct cns3xxx_gpio_chip {
struct gpio_chipchip;
+ struct irq_domain *domain;
spinlock_t lock;
void __iomem*base;
- int secondary_irq_base;
};
static struct cns3xxx_gpio_chip cns3xxx_gpio_chips[2];
@@ -127,7 +128,7 @@ static int cns3xxx_gpio_to_irq(struct gpio_chip *chip,
unsigned pin)
struct cns3xxx_gpio_chip *cchip =
container_of(chip, struct cns3xxx_gpio_chip, chip);
- return cchip-secondary_irq_base + pin;
+ return irq_find_mapping(cchip-domain, pin);
}
@@ -152,7 +153,7 @@ static void cns3xxx_gpio_irq_handler(unsigned int irq,
struct irq_desc *desc)
for (i = 0; i 32; i++) {
if (reg (1 i)) {
/* let the generic IRQ layer handle an interrupt */
- generic_handle_irq(cchip-secondary_irq_base + i);
+ generic_handle_irq(irq_find_mapping(cchip-domain, i));
}
}
@@ -163,7 +164,7 @@ static int cns3xxx_gpio_irq_set_type(struct irq_data *d,
u32 irqtype)
{
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
struct cns3xxx_gpio_chip *cchip = gc-private;
- u32 gpio = d-irq - cchip-secondary_irq_base;
+ u32 gpio = d-hwirq;
unsigned long flags;
u32 method, edges, type;
@@ -224,6 +225,7 @@ void __init cns3xxx_gpio_init(int gpio_base, int ngpio,
struct irq_chip_generic *gc;
struct irq_chip_type *ct;
char gc_label[16];
+ int irq_base;
if (cns3xxx_gpio_chip_count == ARRAY_SIZE(cns3xxx_gpio_chips))
return;
@@ -243,7 +245,6 @@ void __init cns3xxx_gpio_init(int gpio_base, int ngpio,
cchip-chip.can_sleep = 0;
spin_lock_init(cchip-lock);
cchip-base = (void __iomem *)base;
- cchip-secondary_irq_base = secondary_irq_base;
BUG_ON(gpiochip_add(cchip-chip) 0);
cns3xxx_gpio_chip_count++;
@@ -251,11 +252,22 @@ void __init cns3xxx_gpio_init(int gpio_base, int ngpio,
/* clear GPIO interrupts */
__raw_writel(0x, cchip-base + GPIO_INTERRUPT_CLEAR);
+ irq_base = irq_alloc_descs(-1, secondary_irq_base, ngpio,
+ numa_node_id());
+ if (irq_base 0)
+ goto out_irqdesc_free;
+
+ cchip-domain = irq_domain_add_legacy(NULL, ngpio, irq_base, 0,
+ irq_domain_simple_ops, NULL);
+ if (!cchip-domain)
+ goto out_irqdesc_free;
+
/*
* IRQ chip init
*/
- gc = irq_alloc_generic_chip(cns3xxx_gpio_irq, 1, secondary_irq_base,
+ gc = irq_alloc_generic_chip(cns3xxx_gpio_irq, 1, irq_base,
cchip-base, handle_edge_irq);
+
gc-private = cchip;
ct = gc-chip_types;
@@ -270,7 +282,11 @@ void __init cns3xxx_gpio_init(int gpio_base, int ngpio,
irq_setup_generic_chip(gc, IRQ_MSK(ngpio), IRQ_GC_INIT_MASK_CACHE,
IRQ_NOREQUEST, 0);
-
irq_set_chained_handler(irq, cns3xxx_gpio_irq_handler);
irq_set_handler_data(irq, cchip);
+
+ return;
+
+out_irqdesc_free:
+ irq_free_descs(irq_base, ngpio);
}
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Default dhcp (client) hostname is unset - Luci implies $(hostname)
On Tue, Oct 7, 2014 at 7:02 PM, Justin Vallon justinval...@gmail.com wrote: So either: 1) The dhcp hostname option should be blank to indicate no default value (maintain current behavior) 2) When udhcpc is invoked, it should pass -H $(hostname) in case of default (make backend behave as Luci implies) IMO: I find it nice that many hosts pass their hostname automatically, so that the DHCP active lease list is useful, versus a lot of ? entries and ethernet addresses. So, I would vote for 2. Opinions? Where would this bug get posted? (wiki.openwrt.org is down, so I cannot check the wiki) The wiki is working for me now... That info is stored on a per interface basis in /etc/config/network (see Link[1]) and is not set by default, although it may pull from /etc/config/system (see Link[2]) if unset in /etc/config/network. The default value in /etc/config/system is 'OpenWrt' Link[1]: http://wiki.openwrt.org/doc/uci/network#protocol.dhcp Link[2]: http://wiki.openwrt.org/doc/uci/system Aaron Z A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. — Robert Heinlein, Time Enough for Love ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] desperately seeking info on this weird MT7620A/MT7610EN dev board
On Tue, Oct 7, 2014 at 7:06 PM, Robert P. J. Day rpj...@crashcourse.ca wrote: finally, given that this board looks like *someone's* dev board, would anyone know where it might have come from? there's no manufacturer name on it anywhere. in the ramips dts file MT7620a.dts, i can see a reference to a Ralink MT7620a + MT7610e evaluation board. might that be it? i'd post a pic but i signed an NDA, although since no one has any idea where the board came from, i'm not sure what i'd be disclosing by posting a pic. i'm open to any information i can get, particularly support for that MT7610EN radio chip. thanks muchly. Any chance that it has an FCC ID, chip model numbers or other regulatory body unique number on it that you could share? I realize that you are in Canada and its a off brand board but you never know, the OEM might have used the same FCC number when they cloned the board... Aaron Z A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. — Robert Heinlein, Time Enough for Love ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
