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 --- 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 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 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 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
---
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/mac8
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
---
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 [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
---
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
[OpenWrt-Devel] iproute2 / macvlan-problem
since some weeks i have problems using 'macvlan'. it works with r41037 / kernel 3.10.36 and does not work with r42830 / kernel 3.10.49 or .55 what i do is this: brctl addbr br-test brctl addif br-test $WIFIDEV ip link set dev br-test up insmod macvlan ip link add link br-test subdev0 address 02:ca:ff:ee:00:02 type macvlan it should create 'subdev0' which is connected to 'br-test', e.g: root@box:~ ip address show 9: br-test: mtu 1500 qdisc noqueue state UP group default link/ether b2:48:7a:a5:96:2e brd ff:ff:ff:ff:ff:ff inet6 fe80::b048:7aff:fea5:962e/64 scope link tentative valid_lft forever preferred_lft forever 10: subdev0@br-test: mtu 1500 qdisc noop state DOWN group default link/ether 02:ca:ff:ee:00:02 brd ff:ff:ff:ff:ff:ff root@box:~ brctl show bridge name bridge id STP enabled interfaces br-test 8000.b2487aa5962e no wlan0-1 but now it returns: root@box-r42830:~ ip link add link br-test subdev0 address 02:ca:ff:ee:00:02 type macvlan Error: argument "subdev0" is wrong: Unknown device the kmodule 'macvlan' is loaded according to 'lsmod'. and no errors are in the logs. there where some updates regarding iproute2, maybe this is related? see: git log --grep iproute2 bye, bastian ___ 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 >To: mailinglist >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] [PATCH] Linux 3.16 support on mvebu
Hi, On Mon, Oct 06, 2014 at 01:47:28PM +0200, Maxime Ripard wrote: > Hi, > > Since this patchset is rather big, I didn't posted it by mail, but as > suggested on the openwrt documentation, hosted these patches on a > server. > > This serie of patches aims at using the Linux 3.16 kernel on the mvebu > SoCs. > > The first patch ports the existing 3.14 patches to 3.16, and creates a > generic configuration for it. > > http://free-electrons.com/~maxime/pub/openwrt-3.16/0001-linux-Add-3.16-support.patch > > The second patch does pretty much the same thing but for the mvebu > target. > > http://free-electrons.com/~maxime/pub/openwrt-3.16/0002-mvebu-Add-3.16-kernel-patches-and-configuration.patch > > And the last one switches the mvebu kernel version to 3.16. > > http://free-electrons.com/~maxime/pub/openwrt-3.16/0003-mvebu-Switch-to-3.16.patch > > Since a lot of changes got introduced between 3.14 and 3.16, such as > the support for the newer Marvell SoCs, the Armada 375 and 38X, it > will need some additional work to get it to work on these, but that's > to be done in a separate set. Just an update on that, I just found out that there was an issue in the squashfs xz compression options handling, so it's probably not a very good idea to merge as is. I'll look into it and send a v2. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ 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] [luci] [DISCUSSION] How to support LuCI applications not in OpenWrt packages repository
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. ~ 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: default distance-settings 0
Message: 1 Date: Tue, 7 Oct 2014 17:17:40 +0200 From: Bastian Bittorf To: mailinglist 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 [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
Re: [OpenWrt-Devel] [luci] [DISCUSSION] How to support LuCI applications not in OpenWrt packages repository
Am 07.10.2014 um 20:16 schrieb Nikos Mavrogiannopoulos: > 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) > And possibly close TRAC on LuCI because I've seen a lot users posting inside OpenWrt's forum and ticket system. >From user point of view it's absolutely OK. The "user" only downloads the LuCI app to get the functionality mostly not knowing what is happening behind. Thats the reason for a GUI. I think we want to give more functionality than manufactures are doing, the reason why technically interested users start with OpenWrt like I did 2 years ago. 1st step was to use my box with the prebuild image and the Web UI and starting from there to find a way into the internals of OpenWrt. For me still many things are not clear, but I continue to "try and error" to find out. ___ 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 20:16 schrieb Nikos Mavrogiannopoulos: > 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) > Time is really a good point. I've seen the last month mostly you Jow from the LuCI developer team listed at LuCI page acting here. I think it's your free time you are "working" here on the projects. More committers should be a THE solution. ___ 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
---
.../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
#include
#include
+#include
#include
@@ -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 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 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
Re: [OpenWrt-Devel] desperately seeking info on this weird MT7620A/MT7610EN dev board
Another thought- Are you reading the version number from the chip themselves (hardware)? How does the current openwrt bootlog identify them? Same way? On Tue, Oct 7, 2014 at 5:51 PM, Aaron Z wrote: > On Tue, Oct 7, 2014 at 7:06 PM, Robert P. J. Day > 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 > ___ 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 10/7/14 8:46 PM, Aaron Z wrote:
> On Tue, Oct 7, 2014 at 7:02 PM, Justin Vallon 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
>
The docs for uci network.${iface}.hostname say that there is no default
hostname submitted in the DHCP request. However, Luci seems to imply
that the default is $HOSTNAME because it shows $HOSTNAME if the field is
unset. Your guess ("it may pull from ...") appears to be incorrect, and
is/was my confusion as well.
Fixing Luci would seem to be straightforward (default is ""). Fixing
the backend (default is "$HOSTNAME") would be a change of behavior. I
will look into both options.
--
-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
