[OpenWrt-Devel] Unblockable mutlicast
If I posted from the right account, it would help for asking asking a question... At the risk of seeming a complete n00b despite being far from it, why am I seeing this in iftop on BB-rc3 using iftop on the WAN? all-systems.mcast.net = 7.249.33.1 all-systems.mcast.net = 7.249.33.1 Which whois says is an arin.net IP (which is early arpanet DoD network IIRC). It cannot be blocked via iptables which has me curious as to exactly what kernel subsystem is doing this and why. Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Fix/Enable OpenWrt External Toolchain Building ImageBuilder and SDK (and have them work)
Hi all, The following patch both fixes using an openwrt external toolchain (that is in menuconfig using the option to build a toolchain, and feeding that back into another openwrt build as an external toolchain, which if you're not constantly following every commit in trunk (or to a certain extent even if you are, because even then toolchain doesn't change that often), saves a great deal of build time since the toolchain is one of the portions of the build that takes longest and is not parallelized (or at least not much)) to build a working ImageBuilder and SDK (the resulting ImageBuilder and SDK (or at least the SDK) require that the Toolchain directory be referenced in their .configs). This patch should be fairly non-controversial or painful for anyone, but I am posting for review of submitting because I have been on a long hiatus, and my previous recent commit (for a personal patch, unlike this patch, which comes from a client) as a I came back was rather a disaster (though at least the concept was appreciated (the -fat image for dir825 which allows to use the full flash of the dir825 instead of only about 6MB that the stock images use and the default caldata position allows). I am hoping this gets no complaints and I can just commit the patch, but if there are issues, please let me know and I will try to address them. I probably can't spend a lot of time on it, since my client isn't likely to pay for extensive amounts of time massaging patches to get them accepted upstream when they work for them, so please keep that in mind when asking for changes. I am hoping the that various patches I will be sending don't require a lot of managing to be useful/manageable in openwrt proper, since I'd like to see openwrt benefit from the time I've spent away, but as I've said I don't have a lot of paid time to get them integrated. In include patch both inline and as attachment so that hopefully everyone can get a non-mangled using their preferred method of dealing with patches. Signed-Off-By: Daniel Dickinson csh...@openwrt.org Patch follows: Index: openwrt/target/imagebuilder/Config.in === --- openwrt.orig/target/imagebuilder/Config.in 2012-09-28 20:22:39.0 -0400 +++ openwrt/target/imagebuilder/Config.in 2012-10-10 20:56:25.372687867 -0400 @@ -2,7 +2,7 @@ bool Build the OpenWrt Image Builder depends !TARGET_ROOTFS_INITRAMFS depends !PROFILE_KCONFIG - depends !EXTERNAL_TOOLCHAIN + depends !EXTERNAL_TOOLCHAIN || EXTERNAL_UCLIBC help This is essentially a stripped-down version of the buildroot with precompiled packages, kernel image and image building tools. Index: openwrt/target/sdk/Config.in === --- openwrt.orig/target/sdk/Config.in 2012-09-28 20:22:41.0 -0400 +++ openwrt/target/sdk/Config.in2012-10-10 20:56:25.372687867 -0400 @@ -1,6 +1,6 @@ config SDK bool Build the OpenWrt SDK - depends !EXTERNAL_TOOLCHAIN + depends !EXTERNAL_TOOLCHAIN || EXTERNAL_UCLIBC help This is essentially a stripped-down version of the buildroot with a precompiled toolchain. It can be used to develop and Index: openwrt/toolchain/Config.in === --- openwrt.orig/toolchain/Config.in2012-09-28 20:22:41.0 -0400 +++ openwrt/toolchain/Config.in 2012-10-10 20:56:25.376687693 -0400 @@ -14,6 +14,13 @@ help If enabled, OpenWrt will compile using the native toolchain for your host instead of compiling one + config EXTERNAL_UCLIBC + bool + prompt External toolchain uses uClibc if DEVEL + depends EXTERNAL_TOOLCHAIN !NATIVE_TOOLCHAIN + help + If enabled, OpenWrt will treat the external toolchain as a uClibc toolchain + config TARGET_NAME string prompt Target name if DEVEL @@ -171,7 +178,7 @@ config USE_UCLIBC bool - default y if !TOOLCHAINOPTS !EXTERNAL_TOOLCHAIN !NATIVE_TOOLCHAIN + default y if !TOOLCHAINOPTS !EXTERNAL_TOOLCHAIN !NATIVE_TOOLCHAIN || EXTERNAL_UCLIBC config USE_EXTERNAL_LIBC bool Index: openwrt/toolchain/Makefile === --- openwrt.orig/toolchain/Makefile 2012-09-28 20:22:41.0 -0400 +++ openwrt/toolchain/Makefile 2012-10-10 20:56:25.376687693 -0400 @@ -29,9 +29,11 @@ # subdirectories to descend into $(curdir)/builddirs := $(if $(CONFIG_GDB),gdb) $(if $(CONFIG_INSIGHT),insight) $(if $(CONFIG_EXTERNAL_TOOLCHAIN),wrapper,kernel-headers binutils gcc/minimal gcc/initial gcc/final $(LIBC)/headers $(LIBC)) +ifndef CONFIG_EXTERNAL_TOOLCHAIN ifdef CONFIG_USE_UCLIBC $(curdir)/builddirs += $(LIBC)/utils
Re: [OpenWrt-Devel] [PATCH] Fix/Enable OpenWrt External Toolchain Building ImageBuilder and SDK (and have them work)
Oh, one thing I forgot was to rebase against trunk. This is based on a version of attitude_adjustment a few days to a week or two ago. On 01/11/2012 12:49 AM, Daniel Dickinson wrote: Hi all, The following patch both fixes using an openwrt external toolchain (that is in menuconfig using the option to build a toolchain, and feeding that back into another openwrt build as an external toolchain, which if you're not constantly following every commit in trunk (or to a certain extent even if you are, because even then toolchain doesn't change that often), saves a great deal of build time since the toolchain is one of the portions of the build that takes longest and is not parallelized (or at least not much)) to build a working ImageBuilder and SDK (the resulting ImageBuilder and SDK (or at least the SDK) require that the Toolchain directory be referenced in their .configs). This patch should be fairly non-controversial or painful for anyone, but I am posting for review of submitting because I have been on a long hiatus, and my previous recent commit (for a personal patch, unlike this patch, which comes from a client) as a I came back was rather a disaster (though at least the concept was appreciated (the -fat image for dir825 which allows to use the full flash of the dir825 instead of only about 6MB that the stock images use and the default caldata position allows). I am hoping this gets no complaints and I can just commit the patch, but if there are issues, please let me know and I will try to address them. I probably can't spend a lot of time on it, since my client isn't likely to pay for extensive amounts of time massaging patches to get them accepted upstream when they work for them, so please keep that in mind when asking for changes. I am hoping the that various patches I will be sending don't require a lot of managing to be useful/manageable in openwrt proper, since I'd like to see openwrt benefit from the time I've spent away, but as I've said I don't have a lot of paid time to get them integrated. In include patch both inline and as attachment so that hopefully everyone can get a non-mangled using their preferred method of dealing with patches. Signed-Off-By: Daniel Dickinson csh...@openwrt.org Patch follows: Index: openwrt/target/imagebuilder/Config.in === --- openwrt.orig/target/imagebuilder/Config.in2012-09-28 20:22:39.0 -0400 +++ openwrt/target/imagebuilder/Config.in 2012-10-10 20:56:25.372687867 -0400 @@ -2,7 +2,7 @@ bool Build the OpenWrt Image Builder depends !TARGET_ROOTFS_INITRAMFS depends !PROFILE_KCONFIG - depends !EXTERNAL_TOOLCHAIN + depends !EXTERNAL_TOOLCHAIN || EXTERNAL_UCLIBC help This is essentially a stripped-down version of the buildroot with precompiled packages, kernel image and image building tools. Index: openwrt/target/sdk/Config.in === --- openwrt.orig/target/sdk/Config.in 2012-09-28 20:22:41.0 -0400 +++ openwrt/target/sdk/Config.in 2012-10-10 20:56:25.372687867 -0400 @@ -1,6 +1,6 @@ config SDK bool Build the OpenWrt SDK - depends !EXTERNAL_TOOLCHAIN + depends !EXTERNAL_TOOLCHAIN || EXTERNAL_UCLIBC help This is essentially a stripped-down version of the buildroot with a precompiled toolchain. It can be used to develop and Index: openwrt/toolchain/Config.in === --- openwrt.orig/toolchain/Config.in 2012-09-28 20:22:41.0 -0400 +++ openwrt/toolchain/Config.in 2012-10-10 20:56:25.376687693 -0400 @@ -14,6 +14,13 @@ help If enabled, OpenWrt will compile using the native toolchain for your host instead of compiling one + config EXTERNAL_UCLIBC + bool + prompt External toolchain uses uClibc if DEVEL + depends EXTERNAL_TOOLCHAIN !NATIVE_TOOLCHAIN + help +If enabled, OpenWrt will treat the external toolchain as a uClibc toolchain + config TARGET_NAME string prompt Target name if DEVEL @@ -171,7 +178,7 @@ config USE_UCLIBC bool - default y if !TOOLCHAINOPTS !EXTERNAL_TOOLCHAIN !NATIVE_TOOLCHAIN + default y if !TOOLCHAINOPTS !EXTERNAL_TOOLCHAIN !NATIVE_TOOLCHAIN || EXTERNAL_UCLIBC config USE_EXTERNAL_LIBC bool Index: openwrt/toolchain/Makefile === --- openwrt.orig/toolchain/Makefile 2012-09-28 20:22:41.0 -0400 +++ openwrt/toolchain/Makefile2012-10-10 20:56:25.376687693 -0400 @@ -29,9 +29,11 @@ # subdirectories to descend into $(curdir)/builddirs := $(if $(CONFIG_GDB),gdb
Re: [OpenWrt-Devel] [PATCH] Fix/Enable OpenWrt External Toolchain Building ImageBuilder and SDK (and have them work)
This version is based against trunk as of now and fixes the SDK tarball name.
The following patch both fixes using an openwrt external toolchain
(that is in menuconfig using the option to build a toolchain, and feeding
that back into another openwrt build as an external toolchain, which if you're
not
constantly following every commit in trunk (or to a certain extent even if you
are,
because even then toolchain doesn't change that often), saves a great deal of
build time
since the toolchain is one of the portions of the build that takes longest and
is not
parallelized (or at least not much)) to build a working ImageBuilder and SDK
(the resulting
ImageBuilder and SDK (or at least the SDK) require that the Toolchain directory
be referenced
in their .configs).
This patch should be fairly non-controversial or painful for anyone, but I am
posting for review
of submitting because I have been on a long hiatus, and my previous recent
commit (for a personal patch,
unlike this patch, which comes from a client) as a I came back was rather a
disaster (though at least
the concept was appreciated (the -fat image for dir825 which allows to use the
full flash of the dir825
instead of only about 6MB that the stock images use and the default caldata
position allows).
I am hoping this gets no complaints and I can just commit the patch, but if
there are issues, please let me
know and I will try to address them. I probably can't spend a lot of time on
it, since my client isn't likely to pay for
extensive amounts of time massaging patches to get them accepted upstream when
they work for them, so please keep
that in mind when asking for changes. I am hoping the that various patches I
will be sending don't require a lot
of managing to be useful/manageable in openwrt proper, since I'd like to see
openwrt benefit from the time I've
spent away, but as I've said I don't have a lot of paid time to get them
integrated.
In include patch both inline and as attachment so that hopefully everyone can
get a non-mangled using their
preferred method of dealing with patches.
Signed-off-by: DanielDickinson dan...@powercloudsystems.com
---
package/toolchain/Makefile | 10 +++---
rules.mk |3 +++
target/imagebuilder/Config.in |2 +-
target/imagebuilder/files/Makefile |7 ++-
target/sdk/Config.in |2 +-
target/sdk/Makefile|8 +++-
toolchain/Config.in|9 -
toolchain/Makefile |2 ++
toolchain/wrapper/Makefile |4
9 files changed, 39 insertions(+), 8 deletions(-)
diff --git a/package/toolchain/Makefile b/package/toolchain/Makefile
index c194a34..00923f9 100644
--- a/package/toolchain/Makefile
+++ b/package/toolchain/Makefile
@@ -138,7 +138,8 @@ define Package/libc/config
string
prompt libc shared library files (use wildcards)
depends EXTERNAL_TOOLCHAIN PACKAGE_libc
- default ./lib/ld{-*.so,-linux*.so.*}
./lib/lib{anl,c,cidn,crypt,dl,m,nsl,nss_dns,nss_files,resolv,util}{-*.so,.so.*}
+ default ./lib/ld{-*.so,-linux*.so.*}
./lib/lib{anl,c,cidn,crypt,dl,m,nsl,nss_dns,nss_files,resolv,util}{-*.so,.so.*,.so}
if !EXTERNAL_UCLIBC
+ default ./lib/ld{-*.so,-*.so.*,-linux*.so.*}
./lib/lib{anl,c,cidn,crypt,dl,m,nsl,nss_dns,nss_files,resolv,util,uClibc}{-*.so,.so.*,.so}
if EXTERNAL_UCLIBC
endmenu
endef
@@ -164,7 +165,7 @@ define Package/libpthread/config
string
prompt libpthread shared library files (use wildcards)
depends EXTERNAL_TOOLCHAIN PACKAGE_libpthread
- default ./lib/libpthread{-*.so,.so.*}
+ default ./lib/libpthread{-*.so,.so.*,.so}
endmenu
endef
@@ -196,7 +197,7 @@ define Package/librt/config
string
prompt librt shared library files (use wildcards)
depends EXTERNAL_TOOLCHAIN PACKAGE_librt
- default ./lib/librt{-*.so,.so.*}
+ default ./lib/librt{-*.so,.so.*,.so}
endmenu
endef
@@ -468,6 +469,7 @@ ifeq ($(CONFIG_EXTERNAL_TOOLCHAIN),)
$(TOOLCHAIN_DIR)/lib/librt.so.* \
$(TOOLCHAIN_DIR)/lib/librt-$(LIBC_SO_VERSION).so \
$(1)/lib/
+ $(if $(CONFIG_EXTERNAL_UCLIBC),$(CP)
$(CONFIG_TOOLCHAIN_ROOT)/lib/librt-*.so $(TOOLCHAIN_DIR)/lib))
endef
define Package/ldd/install
@@ -532,6 +534,7 @@ else
$(INSTALL_DIR) $(1)/dir ; \
$(CP) $(call qstrip,$(CONFIG_LIBPTHREAD_ROOT_DIR))/file
$(1)/dir/ ; \
done ; \
+ $(INSTALL_DIR) $(1)/lib
exit 0
endef
@@ -541,6 +544,7 @@ else
$(INSTALL_DIR) $(1)/dir ; \
$(CP) $(call qstrip,$(CONFIG_LIBRT_ROOT_DIR))/file
$(1)/dir/ ; \
done ; \
+ $(INSTALL_DIR) $(1)/lib
exit 0
endef
Re: [OpenWrt-Devel] [PATCH] Fix/Enable OpenWrt External Toolchain Building ImageBuilder and SDK (and have them work)
External toolchain uses uClibc if DEVEL + depends EXTERNAL_TOOLCHAIN !NATIVE_TOOLCHAIN + help + If enabled, OpenWrt will treat the external toolchain as a uClibc toolchain + config TARGET_NAME string prompt Target name if DEVEL @@ -171,7 +178,7 @@ config INSIGHT config USE_UCLIBC bool - default y if !TOOLCHAINOPTS !EXTERNAL_TOOLCHAIN !NATIVE_TOOLCHAIN + default y if !TOOLCHAINOPTS !EXTERNAL_TOOLCHAIN !NATIVE_TOOLCHAIN || EXTERNAL_UCLIBC config USE_EXTERNAL_LIBC bool diff --git a/toolchain/Makefile b/toolchain/Makefile index bdfb29e..2ec1572 100644 --- a/toolchain/Makefile +++ b/toolchain/Makefile @@ -29,9 +29,11 @@ curdir:=toolchain # subdirectories to descend into $(curdir)/builddirs := $(if $(CONFIG_GDB),gdb) $(if $(CONFIG_INSIGHT),insight) $(if $(CONFIG_EXTERNAL_TOOLCHAIN),wrapper,kernel-headers binutils gcc/minimal gcc/initial gcc/final $(LIBC)/headers $(LIBC)) +ifndef CONFIG_EXTERNAL_TOOLCHAIN ifdef CONFIG_USE_UCLIBC $(curdir)/builddirs += $(LIBC)/utils endif +endif $(curdir)/builddirs-compile:=$($(curdir)/builddirs-prepare) $(curdir)/builddirs-install:=$($(curdir)/builddirs-compile) diff --git a/toolchain/wrapper/Makefile b/toolchain/wrapper/Makefile index 417ed8c..9ae18a3 100644 --- a/toolchain/wrapper/Makefile +++ b/toolchain/wrapper/Makefile @@ -53,6 +53,10 @@ endef define Host/Install $(call toolchain_util,--wrap $(TOOLCHAIN_DIR)/bin) + $(CP) $(CONFIG_TOOLCHAIN_ROOT)/lib/libpthread.so* $(TOOLCHAIN_DIR)/lib + $(CP) $(CONFIG_TOOLCHAIN_ROOT)/lib/librt.so* $(TOOLCHAIN_DIR)/lib + $(CP) $(CONFIG_TOOLCHAIN_ROOT)/lib/libpthread-*.so $(TOOLCHAIN_DIR)/lib + $(CP) $(CONFIG_TOOLCHAIN_ROOT)/lib/librt-*.so $(TOOLCHAIN_DIR)/lib endef define Host/Clean -- Daniel Dickinson PowerCloud Systems, Palo Alto, CA Senior Firmware Engineer (In Canada: Senior Firmware Analyst) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFD][ar71xx] Custom extra mtd partition in mtd_layout
Hi all, I have a client that is carrying around some patches again image Makefile because of custom mtd layouts. Basically they have an extra mtd partition (stealing from rootfs) for data that is persistent across firstboot. My request for discussion, is to see what kinds of things would be reasonable to do so that these partitions could exist, but without keeping patches that are not in openwrt (obviously the answer isn't to just make the normal device (e.g. dir825) have the partition, but I'm not sure of the best generic way to have this happen. Since this client has a router and ap that I will be adding support for, and a profile section, I am thinking that maybe just adding definitions for those devices that have a different name, but generate the same image, except for the mtd_layout (kind of the the Trendnet TEW- whatever that is a DIR825 in almost all but name). What do you think? Regards, Daniel signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/7] [package] mac80211: Make debugging wireless issues with hostapd a little easier
---
package/mac80211/files/lib/wifi/mac80211.sh | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/package/mac80211/files/lib/wifi/mac80211.sh
b/package/mac80211/files/lib/wifi/mac80211.sh
index 4bf035e..4ecb419 100644
--- a/package/mac80211/files/lib/wifi/mac80211.sh
+++ b/package/mac80211/files/lib/wifi/mac80211.sh
@@ -432,7 +432,15 @@ enable_mac80211() {
done
[ -n $start_hostapd ] {
- hostapd -P /var/run/wifi-$phy.pid -B /var/run/hostapd-$phy.conf
|| {
+{
+if [ -n $debug_hostapd ]; then
+echo Debug mode ...
+hostapd -d -P /var/run/wifi-$phy.pid
/var/run/hostapd-$phy.conf
+else
+echo Normal mode ...
+hostapd -P /var/run/wifi-$phy.pid -B
/var/run/hostapd-$phy.conf
+fi
+} || {
echo Failed to start hostapd for $phy
return
}
--
1.7.9.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/7] [package] mac80211: Default second radio to 5g if it does 5g and is US or CA regulatory domain
---
package/mac80211/files/lib/wifi/mac80211.sh |6 ++
1 file changed, 6 insertions(+)
diff --git a/package/mac80211/files/lib/wifi/mac80211.sh
b/package/mac80211/files/lib/wifi/mac80211.sh
index 4ecb419..ad5845b 100644
--- a/package/mac80211/files/lib/wifi/mac80211.sh
+++ b/package/mac80211/files/lib/wifi/mac80211.sh
@@ -611,6 +611,12 @@ detect_mac80211() {
dev_id=option macaddr $(cat
/sys/class/ieee80211/${dev}/macaddress)
fi
+ if [ $mode_band = g ]; then
+ ( iw reg get | grep -q US: || iw reg get | grep -q CA:
) {
+ iw phy $dev info | grep -q '5180 MHz' {
mode_band=a; channel=36 ; }
+ }
+ fi
+
cat EOF
config wifi-device radio$devidx
option type mac80211
--
1.7.9.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/7] [package] mac80211: Use PCS wifi mac address logic for PCS devices
---
package/mac80211/files/lib/wifi/mac80211.sh | 38 ---
1 file changed, 34 insertions(+), 4 deletions(-)
diff --git a/package/mac80211/files/lib/wifi/mac80211.sh
b/package/mac80211/files/lib/wifi/mac80211.sh
index ad5845b..873332d 100644
--- a/package/mac80211/files/lib/wifi/mac80211.sh
+++ b/package/mac80211/files/lib/wifi/mac80211.sh
@@ -295,15 +295,37 @@ get_freq() {
mac80211_generate_mac() {
local off=$1
local mac=$2
+ local radio=$3
local oIFS=$IFS; IFS=:; set -- $mac; IFS=$oIFS
- local b2mask=0x00
- [ $off -gt 0 ] b2mask=0x02
- printf %02x:%s:%s:%s:%02x:%02x \
+ # For cr5000 and cap324 the manufacturer has reserved
+# MAC addresses such that wifi vifs get unique addresses
+ # with their OUI. The models are not necessarily able
+# to be determined by anything other than a file in the
+# firmware (i.e. the board definitions sometimes are
+ # shared with other users of the same basic device, therefore
+ # we use a special file to determine if it's an applicable device).
+
+ if [ -s /usr/cloud/model ]; then
+ case model in $(cat /usr/cloud/model)
+ cr5000 | cap324 )
+ printf %s:%s:%s:%02x:%s:%s\n \
+ $1 $2 $3 \
+ $(( ( 0x$4 0xf0 ) | $off )) \
+ $5 $6
+
+ ;;
+ esac
+else
+ local b2mask=0x00
+ [ $off -gt 0 ] b2mask=0x02
+
+ printf %02x:%s:%s:%s:%02x:%02x \
$(( 0x$1 | $b2mask )) $2 $3 $4 \
$(( (0x$5 + ($off / 0x100)) % 0x100 )) \
$(( (0x$6 + $off) % 0x100 ))
+ fi
}
enable_mac80211() {
@@ -398,7 +420,15 @@ enable_mac80211() {
config_get macaddr $device macaddr
config_get vif_mac $vif macaddr
[ -n $vif_mac ] || {
- vif_mac=$(mac80211_generate_mac $macidx $macaddr)
+ if [ -s /usr/cloud/model ]; then
+ case model in $(cat /usr/cloud/model)
+ cr5000 | cap324 )
+ vif_mac=$(mac80211_generate_mac
$macidx${device#radio} $macaddr)
+ ;;
+ esac
+ else
+ vif_mac=$(mac80211_generate_mac $macidx
$macaddr)
+ fi
macidx=$(($macidx + 1))
}
[ $mode = ap ] || ifconfig $ifname hw ether $vif_mac
--
1.7.9.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 6/7] [failsafe] Allow to disable failsafe
---
package/base-files/Makefile|1 +
.../base-files/files/lib/preinit/30_failsafe_wait | 10 ++
package/base-files/image-config.in | 13 ++---
3 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/package/base-files/Makefile b/package/base-files/Makefile
index 61a109c..95444df 100644
--- a/package/base-files/Makefile
+++ b/package/base-files/Makefile
@@ -64,6 +64,7 @@ define ImageConfigOptions
echo 'pi_init_env=$(if
$(CONFIG_TARGET_INIT_ENV),$(CONFIG_TARGET_INIT_ENV),)'
$(1)/lib/preinit/00_preinit.conf
echo 'pi_init_cmd=$(if
$(CONFIG_TARGET_INIT_CMD),$(CONFIG_TARGET_INIT_CMD),/sbin/init)'
$(1)/lib/preinit/00_preinit.conf
echo 'pi_init_suppress_stderr=$(CONFIG_TARGET_INIT_SUPPRESS_STDERR)'
$(1)/lib/preinit/00_preinit.conf
+ echo 'pi_disable_failsafe=$(CONFIG_TARGET_PREINIT_DISABLE_FAILSAFE)'
$(1)/lib/preinit/00_preinit.conf
echo 'pi_no_network=$(CONFIG_TARGET_PREINIT_NO_NETWORK)'
$(1)/lib/preinit/00_preinit.conf
echo 'pi_ifname=$(if
$(CONFIG_TARGET_PREINIT_IFNAME),$(CONFIG_TARGET_PREINIT_IFNAME),)'
$(1)/lib/preinit/00_preinit.conf
echo 'pi_ip=$(if
$(CONFIG_TARGET_PREINIT_IP),$(CONFIG_TARGET_PREINIT_IP),192.168.1.1)'
$(1)/lib/preinit/00_preinit.conf
diff --git a/package/base-files/files/lib/preinit/30_failsafe_wait
b/package/base-files/files/lib/preinit/30_failsafe_wait
index 04dc57d..2275209 100644
--- a/package/base-files/files/lib/preinit/30_failsafe_wait
+++ b/package/base-files/files/lib/preinit/30_failsafe_wait
@@ -75,10 +75,12 @@ fs_wait_for_key () {
failsafe_wait() {
FAILSAFE=
-pi_failsafe_net_message=true
-preinit_net_echo Please press button now to enter failsafe
-pi_failsafe_net_message=false
-fs_wait_for_key f 'to enter failsafe mode' $fs_failsafe_wait_timeout
FAILSAFE=true export FAILSAFE
+if [ $pi_disable_failsafe != y ]; then
+ pi_failsafe_net_message=true
+ preinit_net_echo Please press button now to enter failsafe
+ pi_failsafe_net_message=false
+ fs_wait_for_key f 'to enter failsafe mode' $fs_failsafe_wait_timeout
FAILSAFE=true export FAILSAFE
+fi
}
boot_hook_add preinit_main failsafe_wait
diff --git a/package/base-files/image-config.in
b/package/base-files/image-config.in
index 021700a..478e895 100644
--- a/package/base-files/image-config.in
+++ b/package/base-files/image-config.in
@@ -32,6 +32,14 @@ config TARGET_PREINIT_TIMEOUT
How long to wait for failsafe mode to be entered before
continuing with a regular boot if failsafe not selected.
+config TARGET_PREINIT_DISABLE_FAILSAFE
+ bool
+ prompt Disable failsafe mode if PREINITOPT
+ default n
+ help
+ Remove failsafe mode altogether (that is don't emit failsafe
message, and
+ don't have option to enter failsafe mode, ever)
+
config TARGET_PREINIT_NO_NETWORK
bool
prompt Drop networking from preinit if PREINITOPT
@@ -53,9 +61,8 @@ config TARGET_PREINIT_SHOW_NETMSG
config TARGET_PREINIT_SUPPRESS_FAILSAFE_NETMSG
bool
- prompt Suppress network message indicating failsafe if PREINITOPT
- default n if !TARGET_PREINIT_NO_NETWORK
- default y if TARGET_PREINIT_NO_NETWORK
+ prompt Suppress network message indicating failsafe if PREINITOPT
!TARGET_PREINIT_NO_NETWORK !TARGET_PREINIT_DISABLE_FAILSAFE
+ default n
help
If Show all preinit network messages above is not set, then
setting this option suppresses the only message that would be
--
1.7.9.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 5/7] [preinit] Allow disabling preinit networking
This is useful when using vlans as otherwise on boot there is cross-vlan leakage
---
package/base-files/Makefile|1 +
.../files/lib/preinit/10_indicate_preinit | 39 +++-
package/base-files/image-config.in | 15 +++-
3 files changed, 37 insertions(+), 18 deletions(-)
diff --git a/package/base-files/Makefile b/package/base-files/Makefile
index 27ce051..61a109c 100644
--- a/package/base-files/Makefile
+++ b/package/base-files/Makefile
@@ -64,6 +64,7 @@ define ImageConfigOptions
echo 'pi_init_env=$(if
$(CONFIG_TARGET_INIT_ENV),$(CONFIG_TARGET_INIT_ENV),)'
$(1)/lib/preinit/00_preinit.conf
echo 'pi_init_cmd=$(if
$(CONFIG_TARGET_INIT_CMD),$(CONFIG_TARGET_INIT_CMD),/sbin/init)'
$(1)/lib/preinit/00_preinit.conf
echo 'pi_init_suppress_stderr=$(CONFIG_TARGET_INIT_SUPPRESS_STDERR)'
$(1)/lib/preinit/00_preinit.conf
+ echo 'pi_no_network=$(CONFIG_TARGET_PREINIT_NO_NETWORK)'
$(1)/lib/preinit/00_preinit.conf
echo 'pi_ifname=$(if
$(CONFIG_TARGET_PREINIT_IFNAME),$(CONFIG_TARGET_PREINIT_IFNAME),)'
$(1)/lib/preinit/00_preinit.conf
echo 'pi_ip=$(if
$(CONFIG_TARGET_PREINIT_IP),$(CONFIG_TARGET_PREINIT_IP),192.168.1.1)'
$(1)/lib/preinit/00_preinit.conf
echo 'pi_netmask=$(if
$(CONFIG_TARGET_PREINIT_NETMASK),$(CONFIG_TARGET_PREINIT_NETMASK),255.255.255.0)'
$(1)/lib/preinit/00_preinit.conf
diff --git a/package/base-files/files/lib/preinit/10_indicate_preinit
b/package/base-files/files/lib/preinit/10_indicate_preinit
index ab69305..84af50c 100644
--- a/package/base-files/files/lib/preinit/10_indicate_preinit
+++ b/package/base-files/files/lib/preinit/10_indicate_preinit
@@ -3,37 +3,42 @@
# Copyright (C) 2010 Vertical Communications
preinit_ip() {
-# if the preinit interface isn't specified and ifname is set in
-# preinit.arch use that interface
-if [ -z $pi_ifname ]; then
- pi_ifname=$ifname
-fi
-
-[ -n $pi_ifname ] grep -q $pi_ifname /proc/net/dev {
- ifconfig $pi_ifname $pi_ip netmask $pi_netmask broadcast $pi_broadcast
up
-}
+if [ $pi_no_network != y ]; then
+ # if the preinit interface isn't specified and ifname is set in
+ # preinit.arch use that interface
+ if [ -z $pi_ifname ]; then
+ pi_ifname=$ifname
+ fi
+
+ [ -n $pi_ifname ] grep -q $pi_ifname /proc/net/dev {
+ ifconfig $pi_ifname $pi_ip netmask $pi_netmask broadcast
$pi_broadcast up
+ }
+ fi
}
preinit_ip_deconfig() {
-[ -n $pi_ifname ] grep -q $pi_ifname /proc/net/dev {
- ifconfig $pi_ifname 0.0.0.0 down
-}
+if [ $pi_no_network != y ]; then
+ [ -n $pi_ifname ] grep -q $pi_ifname /proc/net/dev {
+ ifconfig $pi_ifname 0.0.0.0 down
+ }
+fi
}
preinit_net_echo() {
+if [ $pi_no_network != y ]; then
[ -n $pi_ifname ] grep -q $pi_ifname /proc/net/dev {
- {
[ $pi_preinit_net_messages = y ] || {
[ $pi_failsafe_net_message = true ]
[ $pi_preinit_no_failsafe_netmsg != y ]
}
-
- } netmsg $pi_broadcast $1
- }
+ } netmsg $pi_broadcast $1
+ fi
}
preinit_echo() {
-preinit_net_echo $1
+if [ $pi_no_network != y ]; then
+ preinit_net_echo $1
+fi
echo $1
}
diff --git a/package/base-files/image-config.in
b/package/base-files/image-config.in
index ac08c8d..021700a 100644
--- a/package/base-files/image-config.in
+++ b/package/base-files/image-config.in
@@ -32,10 +32,18 @@ config TARGET_PREINIT_TIMEOUT
How long to wait for failsafe mode to be entered before
continuing with a regular boot if failsafe not selected.
+config TARGET_PREINIT_NO_NETWORK
+ bool
+ prompt Drop networking from preinit if PREINITOPT
+ default n
+ help
+ Disable preinit (and failsafe) networking completely
+
config TARGET_PREINIT_SHOW_NETMSG
bool
prompt Show all preinit network messages if PREINITOPT
default n
+ depends !TARGET_PREINIT_NO_NETWORK
help
Show preinit all network messages (via netmsg broadcast), not
only
the message indicating to press reset to enter failsafe. Note
that
@@ -46,7 +54,8 @@ config TARGET_PREINIT_SHOW_NETMSG
config TARGET_PREINIT_SUPPRESS_FAILSAFE_NETMSG
bool
prompt Suppress network message indicating failsafe if PREINITOPT
- default n
+ default n if !TARGET_PREINIT_NO_NETWORK
+ default y if TARGET_PREINIT_NO_NETWORK
help
If Show all preinit network messages above is not set, then
setting this option suppresses the only message that would be
@@ -57,6 +66,7 @@ config TARGET_PREINIT_IFNAME
string
prompt
[OpenWrt-Devel] [PATCH 7/7] [package] uci: Alternate dir for uci_get and friends
---
package/uci/files/lib/config/uci.sh |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/package/uci/files/lib/config/uci.sh
b/package/uci/files/lib/config/uci.sh
index db84c83..0002917 100644
--- a/package/uci/files/lib/config/uci.sh
+++ b/package/uci/files/lib/config/uci.sh
@@ -36,8 +36,9 @@ uci_load() {
export ${NO_EXPORT:+-n} CONFIG_NUM_SECTIONS=0
export ${NO_EXPORT:+-n} CONFIG_SECTION=
fi
-
- DATA=$(/sbin/uci ${UCI_CONFIG_DIR:+-c $UCI_CONFIG_DIR}
${LOAD_STATE:+-P /var/state} -S -n export $PACKAGE 2/dev/null)
+
+ LOAD_STATE_DIR=${LOAD_STATE_DIR:-/var/state}
+ DATA=$(/sbin/uci ${UCI_CONFIG_DIR:+-c $UCI_CONFIG_DIR}
${LOAD_STATE:+-P $LOAD_STATE_DIR} -S -n export $PACKAGE 2/dev/null)
RET=$?
[ $RET != 0 -o -z $DATA ] || eval $DATA
unset DATA
--
1.7.9.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Various patches from PCS
Greetings, PowerCloud Systems wishes to offer a series of patches for you to consider. The email series associated with this message are patches we think might be of interest to OpenWrt, though some more than others. This patch series includes various useful things like disabling preinit networking, wifi SSID MAC address logic for PCS hardware, and so on. [PATCH 1/7] [package] mac80211: Make debugging wireless issues with [PATCH 2/7] [package] mac80211: Default second radio to 5g if it [PATCH 3/7] [package] mac80211: Use PCS wifi mac address logic for [PATCH 5/7] [preinit] Allow disabling preinit networking [PATCH 6/7] [failsafe] Allow to disable failsafe [PATCH 7/7] [package] uci: Alternate dir for uci_get and friends Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/5] ubdev01 + dlrtdev01: Add support for old PCS devices
Signed-off-by: Daniel Dickinson dan...@powercloudsystems.com --- target/linux/ar71xx/generic/profiles/pcs.mk | 29 + target/linux/ar71xx/image/Makefile | 45 +++ 2 files changed, 74 insertions(+) create mode 100644 target/linux/ar71xx/generic/profiles/pcs.mk diff --git a/target/linux/ar71xx/generic/profiles/pcs.mk b/target/linux/ar71xx/generic/profiles/pcs.mk new file mode 100644 index 000..eaf9699 --- /dev/null +++ b/target/linux/ar71xx/generic/profiles/pcs.mk @@ -0,0 +1,29 @@ +# +# Copyright (C) 2009 OpenWrt.org +# Copyright (C) 2012 PowerCloud Systems +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +define Profile/UBDEV01 + NAME:=PCS ubdev01 model + PACKAGES:= +endef + +define Profile/UBDEV01/Description + Package set optimized for the PCS ubdev01 +endef + +$(eval $(call Profile,UBDEV01)) + +define Profile/DLRTDEV01 + NAME:=PCS dlrtdev01 model + PACKAGES:=kmod-usb-core kmod-usb-ohci kmod-usb2 kmod-ledtrig-usbdev +endef + +define Profile/DLRTDEV01/Description + Package set optimized for the PCS dlrtdev01 +endef + +$(eval $(call Profile,DLRTDEV01)) diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile index 31ba806..2bf66cb 100644 --- a/target/linux/ar71xx/image/Makefile +++ b/target/linux/ar71xx/image/Makefile @@ -174,9 +174,12 @@ db120_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,6336k(rootfs),1 dir825b1_mtdlayout=mtdparts=spi0.0:256k(uboot)ro,64k(config)ro,1024k(kernel),5184k(rootfs),64k(caldata)ro,1600k(unknown)ro,6208k@0x5(firmware),64k@0x7f(caldata_copy) dir825b1_mtdlayout_fat=mtdparts=spi0.0:256k(uboot)ro,64k(config)ro,1024k(kernel),6784k(rootfs),64k(caldata)ro,7808k@0x5(firmware),64k@0x66(caldata_orig),6208k@0x5(firmware_orig) ew-dorin_mtdlayout_4M=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env),1024k(kernel),2688k(rootfs),64k(art),3712k@0x5(firmware) +dlrtdev_mtdlayout=mtdparts=spi0.0:256k(uboot)ro,64k(config)ro,1024k(kernel),5184k(rootfs),64k(caldata)ro,640k(certs),960k(unknown)ro,6208k@0x5(firmware),64k@0x7f(caldata_copy) +dlrtdev_mtdlayout_fat=mtdparts=spi0.0:256k(uboot)ro,64k(config)ro,1024k(kernel),6544k(rootfs),640k(certs),64k(caldata)ro,7168k@0x5(firmware),64k@0x66(caldata_orig),6208k@0x5(firmware_orig) pb92_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,2752k(rootfs),896k(kernel),64k(nvram),64k(art)ro,3648k@0x5(firmware) planex_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,960k(kernel),6784k(rootfs),128k(art)ro,7744k@0x5(firmware) ubntxm_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,1024k(kernel),6528k(rootfs),256k(cfg)ro,64k(EEPROM)ro,7552k@0x5(firmware) +ubdev_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,1024k(kernel),6464k(rootfs),64k(certs),256k(cfg)ro,64k(EEPROM)ro,7488k@0x5(firmware) whrhpg300n_mtdlayout=mtdparts=spi0.0:248k(u-boot)ro,8k(u-boot-env)ro,960k(kernel),2816k(rootfs),64k(art)ro,3712k@0x4(firmware) wndr3700_mtdlayout=mtdparts=spi0.0:320k(u-boot)ro,128k(u-boot-env)ro,1024k(kernel),6656k(rootfs),64k(art)ro,7680k@0x7(firmware) wndr3700v2_mtdlayout=mtdparts=spi0.0:320k(u-boot)ro,128k(u-boot-env)ro,1024k(kernel),14848k(rootfs),64k(art)ro,15872k@0x7(firmware) @@ -229,6 +232,34 @@ define Image/Build/DIR825B1 fi endef +define Image/Build/DLRTDEV + $(call MkuImageLzma,$(2),$(3) $(dlrtdev_mtdlayout)) + $(call Sysupgrade/KRuImage,$(1),$(2),1048576,5308416) + if [ -e $(call sysupname,$(1),$(2)) ]; then \ + ( \ + dd if=$(call sysupname,$(1),$(2)); \ + echo -n $(4); \ + ) $(call imgname,$(1),$(2))-backup-loader.bin; \ + if [ `stat -c%s $(call sysupname,$(1),$(2))` -gt 4194304 ]; then \ + echo Warning: $(call sysupname,$(1),$(2)) is too big; \ + else \ + ( \ + dd if=$(call sysupname,$(1),$(2)) bs=4096k conv=sync; \ + echo -n $(5); \ + ) $(call factoryname,$(1),$(2)); \ + fi; \ + fi + $(call MkuImageLzma,$(2)-fat,$(3) $(dlrtdev_mtdlayout_fat)) + $(call CatFiles,$(KDIR_TMP)/vmlinux-$(2)-fat.uImage,1048576,$(KDIR)/root.$(1),6946816,$(KDIR_TMP)/$(2)-fat.bin) + if [ -e $(KDIR_TMP)/$(2)-fat.bin ]; then \ + echo -n $(KDIR_TMP)/$(2)-fat.dummy; \ + sh $(TOPDIR)/scripts/combined-image.sh \ + $(KDIR_TMP)/$(2)-fat.bin \ + $(KDIR_TMP)/$(2)-fat.dummy \ + $(call sysupname,$(1),$(2)-fat); \ + fi +endef + define Image/Build/WZRHPG30XNH $(call MkuImageLzma,$(2),$(3)) $(call Sysupgrade/KRuImage,$(1),$(2),1048576,31850496) @@ -377,6 +408,18
[OpenWrt-Devel] [PATCH 4/5] ar93x: Add option to disable JTAG, which blocks a GPIO
Signed-off-by: Daniel Dickinson dan...@powercloudsystems.com
---
.../680-MIPS-ath79-ar93x-allow-disable-jtag.patch | 40
.../680-MIPS-ath79-ar93x-allow-disable-jtag.patch | 40
2 files changed, 80 insertions(+)
create mode 100644
target/linux/ar71xx/patches-3.3/680-MIPS-ath79-ar93x-allow-disable-jtag.patch
create mode 100644
target/linux/ar71xx/patches-3.6/680-MIPS-ath79-ar93x-allow-disable-jtag.patch
diff --git
a/target/linux/ar71xx/patches-3.3/680-MIPS-ath79-ar93x-allow-disable-jtag.patch
b/target/linux/ar71xx/patches-3.3/680-MIPS-ath79-ar93x-allow-disable-jtag.patch
new file mode 100644
index 000..a440031
--- /dev/null
+++
b/target/linux/ar71xx/patches-3.3/680-MIPS-ath79-ar93x-allow-disable-jtag.patch
@@ -0,0 +1,40 @@
+Index: linux-3.3.8/arch/mips/ath79/gpio.c
+===
+--- linux-3.3.8.orig/arch/mips/ath79/gpio.c2012-10-25 23:16:10.214087229
-0400
linux-3.3.8/arch/mips/ath79/gpio.c 2012-10-25 23:26:51.257686927 -0400
+@@ -139,6 +139,22 @@
+ .base = 0,
+ };
+
++void ar934x_gpio_function_enable(u32 mask)
++{
++
++ void __iomem *base = ath79_gpio_base;
++ unsigned long flags;
++
++ spin_lock_irqsave(ath79_gpio_lock, flags);
++
++ __raw_writel(__raw_readl(base + AR934X_GPIO_REG_FUNC) | mask,
++ base + AR934X_GPIO_REG_FUNC);
++ /* flush write */
++ __raw_readl(base + AR934X_GPIO_REG_FUNC);
++
++ spin_unlock_irqrestore(ath79_gpio_lock, flags);
++}
++
+ void ath79_gpio_function_enable(u32 mask)
+ {
+ void __iomem *base = ath79_gpio_base;
+Index: linux-3.3.8/arch/mips/include/asm/mach-ath79/ar71xx_regs.h
+===
+--- linux-3.3.8.orig/arch/mips/include/asm/mach-ath79/ar71xx_regs.h
2012-10-25 23:16:10.174088003 -0400
linux-3.3.8/arch/mips/include/asm/mach-ath79/ar71xx_regs.h 2012-10-25
23:26:51.257686927 -0400
+@@ -626,6 +626,8 @@
+ #define AR934X_SRIF_DPLL2_OUTDIV_SHIFT13
+ #define AR934X_SRIF_DPLL2_OUTDIV_MASK 0x7
+
++#define AR934X_GPIO_FUNC_JTAG_DISABLE BIT(1)
++
+ #define AR71XX_GPIO_FUNC_STEREO_ENBIT(17)
+ #define AR71XX_GPIO_FUNC_SLIC_EN BIT(16)
+ #define AR71XX_GPIO_FUNC_SPI_CS2_EN BIT(13)
diff --git
a/target/linux/ar71xx/patches-3.6/680-MIPS-ath79-ar93x-allow-disable-jtag.patch
b/target/linux/ar71xx/patches-3.6/680-MIPS-ath79-ar93x-allow-disable-jtag.patch
new file mode 100644
index 000..cc0956e
--- /dev/null
+++
b/target/linux/ar71xx/patches-3.6/680-MIPS-ath79-ar93x-allow-disable-jtag.patch
@@ -0,0 +1,40 @@
+Index: linux-3.6.5/arch/mips/ath79/gpio.c
+===
+--- linux-3.6.5.orig/arch/mips/ath79/gpio.c2012-11-01 23:56:07.514239441
-0400
linux-3.6.5/arch/mips/ath79/gpio.c 2012-11-01 23:56:15.678091741 -0400
+@@ -139,6 +139,22 @@
+ .base = 0,
+ };
+
++void ar934x_gpio_function_enable(u32 mask)
++{
++
++ void __iomem *base = ath79_gpio_base;
++ unsigned long flags;
++
++ spin_lock_irqsave(ath79_gpio_lock, flags);
++
++ __raw_writel(__raw_readl(base + AR934X_GPIO_REG_FUNC) | mask,
++ base + AR934X_GPIO_REG_FUNC);
++ /* flush write */
++ __raw_readl(base + AR934X_GPIO_REG_FUNC);
++
++ spin_unlock_irqrestore(ath79_gpio_lock, flags);
++}
++
+ void ath79_gpio_function_enable(u32 mask)
+ {
+ void __iomem *base = ath79_gpio_base;
+Index: linux-3.6.5/arch/mips/include/asm/mach-ath79/ar71xx_regs.h
+===
+--- linux-3.6.5.orig/arch/mips/include/asm/mach-ath79/ar71xx_regs.h
2012-11-01 23:56:07.486239947 -0400
linux-3.6.5/arch/mips/include/asm/mach-ath79/ar71xx_regs.h 2012-11-01
23:56:15.678091741 -0400
+@@ -627,6 +627,8 @@
+ #define AR934X_SRIF_DPLL2_OUTDIV_SHIFT13
+ #define AR934X_SRIF_DPLL2_OUTDIV_MASK 0x7
+
++#define AR934X_GPIO_FUNC_JTAG_DISABLE BIT(1)
++
+ #define AR71XX_GPIO_FUNC_STEREO_ENBIT(17)
+ #define AR71XX_GPIO_FUNC_SLIC_EN BIT(16)
+ #define AR71XX_GPIO_FUNC_SPI_CS2_EN BIT(13)
--
1.7.9.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/5] ubnt-unifi-outdoor: Add support for Ubquiti UnifiAP Outdoor (UniFi 2.0 outdoor AP)
Signed-off-by: Daniel Dickinson dan...@powercloudsystems.com
---
.../base-files/etc/defconfig/unifi-outdoor/network | 15 +
target/linux/ar71xx/base-files/lib/ar71xx.sh |3 +
.../ar71xx/base-files/lib/upgrade/platform.sh |3 +-
target/linux/ar71xx/generic/profiles/ubnt.mk | 11
target/linux/ar71xx/image/Makefile |3 +-
.../660-MIPS-ath79-ubnt-xm-add-unifi-outdoor.patch | 68
.../660-MIPS-ath79-ubnt-xm-add-unifi-outdoor.patch | 68
7 files changed, 169 insertions(+), 2 deletions(-)
create mode 100644
target/linux/ar71xx/base-files/etc/defconfig/unifi-outdoor/network
create mode 100644
target/linux/ar71xx/patches-3.3/660-MIPS-ath79-ubnt-xm-add-unifi-outdoor.patch
create mode 100644
target/linux/ar71xx/patches-3.6/660-MIPS-ath79-ubnt-xm-add-unifi-outdoor.patch
diff --git a/target/linux/ar71xx/base-files/etc/defconfig/unifi-outdoor/network
b/target/linux/ar71xx/base-files/etc/defconfig/unifi-outdoor/network
new file mode 100644
index 000..c8f18c2
--- /dev/null
+++ b/target/linux/ar71xx/base-files/etc/defconfig/unifi-outdoor/network
@@ -0,0 +1,15 @@
+# Copyright (C) 2006 OpenWrt.org
+
+config interface loopback
+ option ifname lo
+ option protostatic
+ option ipaddr 127.0.0.1
+ option netmask 255.0.0.0
+
+config interface lan
+ list ifname eth0
+ list ifname eth1
+ option type bridge
+ option protostatic
+ option ipaddr 192.168.1.1
+ option netmask 255.255.255.0
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 430ef8c..7ff43b8 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -387,6 +387,9 @@ ar71xx_board_detect() {
*WLAE-AG300N)
name=wlae-ag300n
;;
+ *UniFiAP Outdoor)
+ name=unifi-outdoor
+ ;;
*WP543)
name=wp543
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 81535ce..5946cf6 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -126,7 +126,8 @@ platform_check_image() {
whr-hp-gn | \
wlae-ag300n | \
nbg460n_550n_550nh | \
- unifi )
+ unifi | \
+ unifi-outdoor )
[ $magic != 2705 ] {
echo Invalid image type.
return 1
diff --git a/target/linux/ar71xx/generic/profiles/ubnt.mk
b/target/linux/ar71xx/generic/profiles/ubnt.mk
index 668171b..dc26956 100644
--- a/target/linux/ar71xx/generic/profiles/ubnt.mk
+++ b/target/linux/ar71xx/generic/profiles/ubnt.mk
@@ -38,6 +38,17 @@ endef
$(eval $(call Profile,UBNTUNIFI))
+define Profile/UBNTUNIFIOUTDOOR
+ NAME:=Ubiquiti UniFiAP Outdoor
+ PACKAGES:=
+endef
+
+define Profile/UBNTUNIFIOUTDOOR/Description
+ Package set optimized for the Ubiquiti UniFiAP Outdoor.
+endef
+
+$(eval $(call Profile,UBNTUNIFIOUTDOOR))
+
define Profile/UBNT
NAME:=Ubiquiti Products
PACKAGES:=kmod-usb-core kmod-usb-ohci kmod-usb2
diff --git a/target/linux/ar71xx/image/Makefile
b/target/linux/ar71xx/image/Makefile
index 2bf66cb..9678d66 100644
--- a/target/linux/ar71xx/image/Makefile
+++ b/target/linux/ar71xx/image/Makefile
@@ -885,6 +885,7 @@ $(eval $(call
SingleProfile,UBNTXM,$(fs_64k),UBNTBULLETM,ubnt-bullet-m,UBNT-BM,t
$(eval $(call
SingleProfile,UBNTXM,$(fs_64k),UBNTROCKETM,ubnt-rocket-m,UBNT-RM,ttyS0,115200,XM,XM,ar7240))
$(eval $(call
SingleProfile,UBNTXM,$(fs_64k),UBNTNANOM,ubnt-nano-m,UBNT-NM,ttyS0,115200,XM,XM,ar7240))
$(eval $(call
SingleProfile,UBNTXM,$(fs_64k),UBNTUNIFI,ubnt-unifi,UBNT-UF,ttyS0,115200,XM,XM,ar7240))
+$(eval $(call
SingleProfile,UBNTXM,$(fs_64k),UBNTUNIFIOUTDOOR,ubnt-unifi-outdoor,UBNT-U20,ttyS0,115200,XM,XM,ar7240))
$(eval $(call
SingleProfile,WHRHPG300N,$(fs_64k),WHRG301N,whr-g301n,WHR-G301N,ttyS0,115200,$$(whrhpg300n_mtdlayout),WHR-G301N))
$(eval $(call
SingleProfile,WHRHPG300N,$(fs_64k),WHRHPG300N,whr-hp-g300n,WHR-HP-G300N,ttyS0,115200,$$(whrhpg300n_mtdlayout),WHR-HP-G300N))
@@ -915,7 +916,7 @@ $(eval $(call MultiProfile,TLWR741,TLWR741NV1 TLWR741NV2
TLWR741NV4))
$(eval $(call MultiProfile,TLWR841,TLWR841NV15 TLWR841NV3 TLWR841NV5
TLWR841NV7 TLWR841NV8))
$(eval $(call MultiProfile,TLWR941,TLWR941NV2 TLWR941NV3 TLWR941NV4))
$(eval $(call MultiProfile,TLWDR4300,TLWDR3600V1 TLWDR4300V1 TLWDR4310V1))
-$(eval $(call MultiProfile,UBNT,UBNTAIRROUTER UBNTRS UBNTRSPRO UBNTLSSR71
UBNTBULLETM UBNTROCKETM UBNTNANOM UBNTUNIFI))
+$(eval $(call MultiProfile,UBNT,UBNTAIRROUTER UBNTRS UBNTRSPRO UBNTLSSR71
UBNTBULLETM UBNTROCKETM UBNTNANOM UBNTUNIFI UBNTUNIFIOUTDOOR))
$(eval $(call MultiProfile,WNDR3700,WNDR3700V1 WNDR3700V2
[OpenWrt-Devel] [PATCH 5/5] Add support for three PowerCloud devices
Signed-off-by: Daniel Dickinson dan...@powercloudsystems.com
---
target/linux/ar71xx/base-files/etc/diag.sh |6 +
.../ar71xx/base-files/etc/uci-defaults/network | 11 +
target/linux/ar71xx/base-files/lib/ar71xx.sh |6 +
.../ar71xx/base-files/lib/upgrade/platform.sh |2 +
target/linux/ar71xx/config-3.3 |1 +
target/linux/ar71xx/config-3.6 |1 +
target/linux/ar71xx/generic/profiles/pcs.mk| 32 +++
target/linux/ar71xx/image/Makefile |4 +
.../patches-3.3/690-MIPS-ath79-pcs-cr5000.patch| 278
.../patches-3.3/700-MIPS-ath79-pcs-cap324.patch| 173
.../patches-3.6/690-MIPS-ath79-pcs-cr5000.patch| 278
.../patches-3.6/700-MIPS-ath79-pcs-cap324.patch| 173
12 files changed, 965 insertions(+)
create mode 100644
target/linux/ar71xx/patches-3.3/690-MIPS-ath79-pcs-cr5000.patch
create mode 100644
target/linux/ar71xx/patches-3.3/700-MIPS-ath79-pcs-cap324.patch
create mode 100644
target/linux/ar71xx/patches-3.6/690-MIPS-ath79-pcs-cr5000.patch
create mode 100644
target/linux/ar71xx/patches-3.6/700-MIPS-ath79-pcs-cap324.patch
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
index 788b628..abdce8d 100755
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -60,6 +60,12 @@ get_status_led() {
db120)
status_led=db120:green:status
;;
+ cr5000)
+ status_led=cr5000:orange:power
+ ;;
+ cap324)
+ status_led=cap324:orange:power
+ ;;
dir-600-a1 |\
dir-615-e4)
status_led=d-link:green:power
diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/network
b/target/linux/ar71xx/base-files/etc/uci-defaults/network
index 105f0e9..bb8ddfe 100755
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/network
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/network
@@ -211,6 +211,17 @@ ew-dorin-router)
ucidef_add_switch_vlan eth0 1 0 2 3
;;
+cr5000)
+ ucidef_set_interfaces_lan_wan eth0.1 eth0.2
+ ucidef_add_switch eth0 1 1
+ ucidef_add_switch_vlan eth0 2 0t 5
+ ucidef_add_switch_vlan eth0 1 0t 1 2 3 4
+ ;;
+
+cap324)
+ ucidef_set_interface_lan eth0
+ ;;
+
*)
ucidef_set_interfaces_lan_wan eth0 eth1
;;
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 7ff43b8..65c33fa 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -195,6 +195,12 @@ ar71xx_board_detect() {
*DB120 reference board)
name=db120
;;
+ *CR5000 Cloud Router)
+ name=cr5000
+ ;;
+ *CAP324 Cloud AP)
+ name=cap324
+ ;;
*DIR-600 rev. A1)
name=dir-600-a1
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 5946cf6..b697001 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -102,6 +102,8 @@ platform_check_image() {
;;
ap81 | \
ap83 | \
+ cr5000 | \
+ cap324 | \
dir-600-a1 | \
dir-615-c1 | \
dir-615-e4 | \
diff --git a/target/linux/ar71xx/config-3.3 b/target/linux/ar71xx/config-3.3
index 45e589e..f8e1bf3 100644
--- a/target/linux/ar71xx/config-3.3
+++ b/target/linux/ar71xx/config-3.3
@@ -47,6 +47,7 @@ CONFIG_ATH79_MACH_OM2P=y
CONFIG_ATH79_MACH_PB42=y
CONFIG_ATH79_MACH_PB44=y
CONFIG_ATH79_MACH_PB92=y
+CONFIG_ATH79_MACH_PCS=y
CONFIG_ATH79_MACH_RB2011=y
CONFIG_ATH79_MACH_RB4XX=y
CONFIG_ATH79_MACH_RB750=y
diff --git a/target/linux/ar71xx/config-3.6 b/target/linux/ar71xx/config-3.6
index 80f0698..ce66024 100644
--- a/target/linux/ar71xx/config-3.6
+++ b/target/linux/ar71xx/config-3.6
@@ -50,6 +50,7 @@ CONFIG_ATH79_MACH_OM2P=y
CONFIG_ATH79_MACH_PB42=y
CONFIG_ATH79_MACH_PB44=y
CONFIG_ATH79_MACH_PB92=y
+CONFIG_ATH79_MACH_PCS=y
CONFIG_ATH79_MACH_RB2011=y
CONFIG_ATH79_MACH_RB4XX=y
CONFIG_ATH79_MACH_RB750=y
diff --git a/target/linux/ar71xx/generic/profiles/pcs.mk
b/target/linux/ar71xx/generic/profiles/pcs.mk
index eaf9699..5b3e260 100644
--- a/target/linux/ar71xx/generic/profiles/pcs.mk
+++ b/target/linux/ar71xx/generic/profiles/pcs.mk
@@ -17,6 +17,17 @@ endef
$(eval $(call Profile,UBDEV01))
+define Profile/UBDEVOD
+ NAME:=PCS ubdevod model
+ PACKAGES:=
+endef
+
+define Profile/UBDEVOD/Description
+ Package set optimized for the PCS ubdevod
+endef
+
+$(eval $(call Profile,UBDEVOD))
+
define Profile/DLRTDEV01
NAME:=PCS dlrtdev01 model
[OpenWrt-Devel] [PATCH 3/5] Allow MAC address to come from platform data and calibration data from PCI-e EEPROM
There is a router that users the MAC address for wireless from the platform data
(which gets it from the flash ART partition) and the calibration data from a
PCI-e
card's EEPROM. Here we add support for this.
Signed-off-by: Daniel Dickinson dan...@powercloudsystems.com
---
...-allow-to-disable-bands-via-platform-data.patch | 33
...k-allow-mac-from-data-caldata-from-eeprom.patch | 81
...-allow-mac-from-pdata-caldata-from-eeprom.patch | 80 +++
...-allow-mac-from-pdata-caldata-from-eeprom.patch | 80 +++
4 files changed, 261 insertions(+), 13 deletions(-)
create mode 100644
package/mac80211/patches/b02-ath9k-allow-mac-from-data-caldata-from-eeprom.patch
create mode 100644
target/linux/ar71xx/patches-3.3/670-MIPS-ath79-allow-mac-from-pdata-caldata-from-eeprom.patch
create mode 100644
target/linux/ar71xx/patches-3.6/670-MIPS-ath79-allow-mac-from-pdata-caldata-from-eeprom.patch
diff --git
a/package/mac80211/patches/b01-ath9k-allow-to-disable-bands-via-platform-data.patch
b/package/mac80211/patches/b01-ath9k-allow-to-disable-bands-via-platform-data.patch
index 0a071ff..b2ea738 100644
---
a/package/mac80211/patches/b01-ath9k-allow-to-disable-bands-via-platform-data.patch
+++
b/package/mac80211/patches/b01-ath9k-allow-to-disable-bands-via-platform-data.patch
@@ -1,18 +1,21 @@
a/include/linux/ath9k_platform.h
-+++ b/include/linux/ath9k_platform.h
-@@ -31,6 +31,9 @@ struct ath9k_platform_data {
+Index: compat-wireless-2012-09-07/include/linux/ath9k_platform.h
+===
+--- compat-wireless-2012-09-07.orig/include/linux/ath9k_platform.h
2012-11-02 01:00:58.0 -0400
compat-wireless-2012-09-07/include/linux/ath9k_platform.h 2012-11-02
01:02:11.866637863 -0400
+@@ -31,6 +31,8 @@
bool endian_check;
bool is_clk_25mhz;
+ bool disable_2ghz;
+ bool disable_5ghz;
-+
int (*get_mac_revision)(void);
int (*external_reset)(void);
a/drivers/net/wireless/ath/ath9k/hw.c
-+++ b/drivers/net/wireless/ath/ath9k/hw.c
-@@ -2413,17 +2413,25 @@ int ath9k_hw_fill_cap_info(struct ath_hw
+Index: compat-wireless-2012-09-07/drivers/net/wireless/ath/ath9k/hw.c
+===
+--- compat-wireless-2012-09-07.orig/drivers/net/wireless/ath/ath9k/hw.c
2012-11-02 01:00:59.063918071 -0400
compat-wireless-2012-09-07/drivers/net/wireless/ath/ath9k/hw.c
2012-11-02 01:00:59.659907593 -0400
+@@ -2413,17 +2413,25 @@
}
eeval = ah-eep_ops-get_eeprom(ah, EEP_OP_MODE);
@@ -46,9 +49,11 @@
if (AR_SREV_9485(ah) || AR_SREV_9285(ah) || AR_SREV_9330(ah))
chip_chainmask = 1;
a/drivers/net/wireless/ath/ath9k/hw.h
-+++ b/drivers/net/wireless/ath/ath9k/hw.h
-@@ -927,6 +927,8 @@ struct ath_hw {
+Index: compat-wireless-2012-09-07/drivers/net/wireless/ath/ath9k/hw.h
+===
+--- compat-wireless-2012-09-07.orig/drivers/net/wireless/ath/ath9k/hw.h
2012-11-02 01:00:59.067917999 -0400
compat-wireless-2012-09-07/drivers/net/wireless/ath/ath9k/hw.h
2012-11-02 01:00:59.663907524 -0400
+@@ -927,6 +927,8 @@
bool is_clk_25mhz;
int (*get_mac_revision)(void);
int (*external_reset)(void);
@@ -57,9 +62,11 @@
};
struct ath_bus_ops {
a/drivers/net/wireless/ath/ath9k/init.c
-+++ b/drivers/net/wireless/ath/ath9k/init.c
-@@ -537,6 +537,8 @@ static int ath9k_init_softc(u16 devid, s
+Index: compat-wireless-2012-09-07/drivers/net/wireless/ath/ath9k/init.c
+===
+--- compat-wireless-2012-09-07.orig/drivers/net/wireless/ath/ath9k/init.c
2012-11-02 01:00:58.863921587 -0400
compat-wireless-2012-09-07/drivers/net/wireless/ath/ath9k/init.c
2012-11-02 01:00:59.663907524 -0400
+@@ -537,6 +537,8 @@
ah-is_clk_25mhz = pdata-is_clk_25mhz;
ah-get_mac_revision = pdata-get_mac_revision;
ah-external_reset = pdata-external_reset;
diff --git
a/package/mac80211/patches/b02-ath9k-allow-mac-from-data-caldata-from-eeprom.patch
b/package/mac80211/patches/b02-ath9k-allow-mac-from-data-caldata-from-eeprom.patch
new file mode 100644
index 000..6d14366
--- /dev/null
+++
b/package/mac80211/patches/b02-ath9k-allow-mac-from-data-caldata-from-eeprom.patch
@@ -0,0 +1,81 @@
+Index: compat-wireless-2012-09-07/include/linux/ath9k_platform.h
+===
+--- compat-wireless-2012-09-07.orig/include/linux/ath9k_platform.h
2012-11-02 01:02:11.0 -0400
compat-wireless-2012-09-07/include/linux/ath9k_platform.h 2012-11-02
01:05:31.563122751 -0400
+@@ -33,6 +33,8 @@
+ bool is_clk_25mhz;
+ bool disable_2ghz;
+ bool disable_5ghz;
++ bool no_eeprom_data
[OpenWrt-Devel] Add support for PowerCloud Systems Hardware
Greetings, PowerCloud Systems wishes to offer a series of patches for you to consider. The email series associated with this message are patches we think might be of interest to OpenWrt, though some more than others. This patch series adds support for PCS hardware. [PATCH 1/5] ubdev01 + dlrtdev01: Add support for old PCS devices [PATCH 2/5] ubnt-unifi-outdoor: Add support for Ubquiti UnifiAP [PATCH 3/5] Allow MAC address to come from platform data and [PATCH 4/5] ar93x: Add option to disable JTAG, which blocks a GPIO [PATCH 5/5] Add support for three PowerCloud devices Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 5/7] [preinit] Allow disabling preinit networking
On 10/11/2012 8:35 AM, Felix Fietkau wrote: On 2012-11-09 11:10 PM, Daniel Dickinson wrote: This is useful when using vlans as otherwise on boot there is cross-vlan leakage How about fixing the cross-vlan leakage instead? The issue is that when preinit configures the switch, it configures it without vlans, therefore all the ports are on the same network for the duration of preinit and until init corrects the situation. If on the other hand the switch is down on boot, nothing crosses the port boundaries, and you don't get cross-vlan leakage. At one point some platforms/devices in openwrt used a separate vlan per port, but that has been removed due to issues with failsafe not working in some cases, or confused users for failsafe in others. Regards, Daniel -- Daniel Dickinson PowerCloud Systems, Palo Alto, CA Senior Firmware Engineer (In Canada: Senior Firmware Analyst) signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/7] [package] mac80211: Default second radio to 5g if it does 5g and is US or CA regulatory domain
FYI. I've had some suggestion on how to better handle it, but really
the problem is that this is a check I implemented because Jay requested
the default radio. It really needs to be fixed properly (but I had
forgotten about), and won't work for EU as it is.
Regards,
Daniel
On 10/11/2012 8:33 AM, Felix Fietkau wrote:
On 2012-11-09 11:10 PM, Daniel Dickinson wrote:
---
package/mac80211/files/lib/wifi/mac80211.sh |6 ++
1 file changed, 6 insertions(+)
diff --git a/package/mac80211/files/lib/wifi/mac80211.sh
b/package/mac80211/files/lib/wifi/mac80211.sh
index 4ecb419..ad5845b 100644
--- a/package/mac80211/files/lib/wifi/mac80211.sh
+++ b/package/mac80211/files/lib/wifi/mac80211.sh
@@ -611,6 +611,12 @@ detect_mac80211() {
dev_id=option macaddr $(cat
/sys/class/ieee80211/${dev}/macaddress)
fi
+if [ $mode_band = g ]; then
+( iw reg get | grep -q US: || iw reg get | grep -q CA:
) {
+iw phy $dev info | grep -q '5180 MHz' {
mode_band=a; channel=36 ; }
+}
+fi
+
cat EOF
config wifi-device radio$devidx
option type mac80211
Why? The country code based thing makes no sense to me, please be a bit
more verbose in your patch descriptions ;)
- Felix
--
Daniel Dickinson PowerCloud Systems, Palo Alto, CA Senior Firmware Engineer (In
Canada: Senior Firmware Analyst)
signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 7/7] [package] uci: Alternate dir for uci_get and friends
On 10/11/2012 8:35 AM, Felix Fietkau wrote:
On 2012-11-09 11:10 PM, Daniel Dickinson wrote:
---
package/uci/files/lib/config/uci.sh |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/package/uci/files/lib/config/uci.sh
b/package/uci/files/lib/config/uci.sh
index db84c83..0002917 100644
--- a/package/uci/files/lib/config/uci.sh
+++ b/package/uci/files/lib/config/uci.sh
@@ -36,8 +36,9 @@ uci_load() {
export ${NO_EXPORT:+-n} CONFIG_NUM_SECTIONS=0
export ${NO_EXPORT:+-n} CONFIG_SECTION=
fi
-
-DATA=$(/sbin/uci ${UCI_CONFIG_DIR:+-c $UCI_CONFIG_DIR}
${LOAD_STATE:+-P /var/state} -S -n export $PACKAGE 2/dev/null)
+
+LOAD_STATE_DIR=${LOAD_STATE_DIR:-/var/state}
+DATA=$(/sbin/uci ${UCI_CONFIG_DIR:+-c $UCI_CONFIG_DIR}
${LOAD_STATE:+-P $LOAD_STATE_DIR} -S -n export $PACKAGE 2/dev/null)
RET=$?
[ $RET != 0 -o -z $DATA ] || eval $DATA
unset DATA
Why?
Because we use it? Seriously though, we find it useful for
our use of UCI and thought it didn't harm anything so why not
offer it if it could be useful to others.
Regards,
Daniel
--
Daniel Dickinson PowerCloud Systems, Palo Alto, CA Senior Firmware Engineer (In
Canada: Senior Firmware Analyst)
signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 5/5] Add support for three PowerCloud devices
Hi Gabor, Thank you for the feedback and UniFi and other patch commit. I have couple of quick questions before reworking the patch. On 14/11/2012 7:18 AM, Gabor Juhos wrote: Hi Daniel, Please split this patch into smaller pieces, as I did that with your UniFi AP patch. More comments inline... Signed-off-by: Daniel Dickinson dan...@powercloudsystems.com --- target/linux/ar71xx/base-files/etc/diag.sh |6 + .../ar71xx/base-files/etc/uci-defaults/network | 11 + target/linux/ar71xx/base-files/lib/ar71xx.sh |6 + .../ar71xx/base-files/lib/upgrade/platform.sh |2 + target/linux/ar71xx/config-3.3 |1 + target/linux/ar71xx/config-3.6 |1 + target/linux/ar71xx/generic/profiles/pcs.mk| 32 +++ target/linux/ar71xx/image/Makefile |4 + .../patches-3.3/690-MIPS-ath79-pcs-cr5000.patch| 278 .../patches-3.3/700-MIPS-ath79-pcs-cap324.patch| 173 .../patches-3.6/690-MIPS-ath79-pcs-cr5000.patch| 278 .../patches-3.6/700-MIPS-ath79-pcs-cap324.patch| 173 12 files changed, 965 insertions(+) create mode 100644 target/linux/ar71xx/patches-3.3/690-MIPS-ath79-pcs-cr5000.patch create mode 100644 target/linux/ar71xx/patches-3.3/700-MIPS-ath79-pcs-cap324.patch create mode 100644 target/linux/ar71xx/patches-3.6/690-MIPS-ath79-pcs-cr5000.patch create mode 100644 target/linux/ar71xx/patches-3.6/700-MIPS-ath79-pcs-cap324.patch ... diff --git a/target/linux/ar71xx/generic/profiles/pcs.mk b/target/linux/ar71xx/generic/profiles/pcs.mk index eaf9699..5b3e260 100644 --- a/target/linux/ar71xx/generic/profiles/pcs.mk +++ b/target/linux/ar71xx/generic/profiles/pcs.mk @@ -17,6 +17,17 @@ endef $(eval $(call Profile,UBDEV01)) +define Profile/UBDEVOD +NAME:=PCS ubdevod model Please use 'PowerCloud Systems' instead of 'PCS' in profile names/descriptions as Felix suggested for the other patch. ... diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile index 9678d66..27f3daa 100644 --- a/target/linux/ar71xx/image/Makefile +++ b/target/linux/ar71xx/image/Makefile @@ -171,6 +171,8 @@ cameo913x_mtdlayout=mtdparts=spi0.0:128k(u-boot)ro,64k(config)ro,960k(kernel),28 cameo933x_mtdlayout=mtdparts=spi0.0:64k(u-boot)ro,64k(art)ro,64k(mac)ro,64k(nvram)ro,192k(language)ro,896k(kernel),2752k(rootfs),3648k@0x7(firmware) cap4200ag_mtdlayout=mtdparts=spi0.0:256k(u-boot),64k(u-boot-env),320k(custom)ro,1536k(kernel),12096k(rootfs),2048k(failsafe),64k(art),13632k@0xa(firmware) db120_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,6336k(rootfs),1408k(kernel),64k(nvram),64k(art)ro,7744k@0x5(firmware) +cr5000_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,1408k(kernel),5696k(rootfs),640k(certs),64k(nvram),64k(art)ro,7104k@0x5(firmware) +cap324_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,1408k(kernel),13888k(rootfs),640k(certs),64k(nvram),64k(art)ro,15296k@0x5(firmware) Please keep these sorted alphabetically. dir825b1_mtdlayout=mtdparts=spi0.0:256k(uboot)ro,64k(config)ro,1024k(kernel),5184k(rootfs),64k(caldata)ro,1600k(unknown)ro,6208k@0x5(firmware),64k@0x7f(caldata_copy) dir825b1_mtdlayout_fat=mtdparts=spi0.0:256k(uboot)ro,64k(config)ro,1024k(kernel),6784k(rootfs),64k(caldata)ro,7808k@0x5(firmware),64k@0x66(caldata_orig),6208k@0x5(firmware_orig) ew-dorin_mtdlayout_4M=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env),1024k(kernel),2688k(rootfs),64k(art),3712k@0x5(firmware) @@ -906,6 +908,8 @@ $(eval $(call SingleProfile,ZyXEL,$(fs_64k),NBG_460N_550N_550NH,nbg460n_550n_550 $(eval $(call SingleProfile,UBDEV,$(fs_64k),UBDEV01,ubdev01,UBNT-UF,ttyS0,115200,XM,XM,ar7240)) $(eval $(call SingleProfile,DLRTDEV,$(fs_64k),DLRTDEV01,dlrtdev01,DIR-825-B1,ttyS0,115200,01AP94-AR7161-RT-080619-00,00AP94-AR7161-RT-080619-00)) +$(eval $(call SingleProfile,UBDEV,$(fs_64k),UBDEVOD,ubdevod,UBNT-U20,ttyS0,115200,XM,XM,ar7240)) +$(eval $(call SingleProfile,AthLzma,$(fs_64k),CR5000,cr5000,CR5000,ttyS0,115200,$$(cr5000_mtdlayout),1441792,5832484,KRuImage)) Keep these sorted as well. $(eval $(call MultiProfile,AP121,AP121_2M AP121_4M)) $(eval $(call MultiProfile,EWDORIN, EWDORINAP EWDORINRT)) diff --git a/target/linux/ar71xx/patches-3.3/690-MIPS-ath79-pcs-cr5000.patch b/target/linux/ar71xx/patches-3.3/690-MIPS-ath79-pcs-cr5000.patch new file mode 100644 index 000..84dcac6 --- /dev/null +++ b/target/linux/ar71xx/patches-3.3/690-MIPS-ath79-pcs-cr5000.patch Use the 611-620 range for the patch name. @@ -0,0 +1,278 @@ +Index: linux-3.3.8/arch/mips/ath79/Kconfig +=== +--- linux-3.3.8.orig/arch/mips/ath79/Kconfig2012-11-01 22:04:55.0 -0400
Re: [OpenWrt-Devel] [PATCH 3/5] Allow MAC address to come from platform data and calibration data from PCI-e EEPROM
On 10/11/2012 8:44 AM, Felix Fietkau wrote:
On 2012-11-09 11:02 PM, Daniel Dickinson wrote:
There is a router that users the MAC address for wireless from the platform
data
(which gets it from the flash ART partition) and the calibration data from a
PCI-e
card's EEPROM. Here we add support for this.
At least for AR9300 the code already checks the platform data's EEPROM
validity. If the pdata contains an empty EEPROM data section, the code
falls back to trying OTP and Serial EEPROM access. Doesn't that make
this patch unnecessary?
There are two things that cause this not to work. The first is
that the platform defintion for ath9k that defines pdata, defines
it as an array, therefore it's size can never be 0.
if (pdata !no_eeprom_data) {
if (off = (ARRAY_SIZE(pdata-eeprom_data))) {
ath_err(common,
%s: eeprom read failed, offset %08x is out of
range\n,
__func__, off);
}
*data = pdata-eeprom_data[off];
} else {
struct ath_hw *ah = (struct ath_hw *) common-ah;
common-ops-read(ah, AR5416_EEPROM_OFFSET +
(off AR5416_EEPROM_S));
if (!ath9k_hw_wait(ah,
AR_EEPROM_STATUS_DATA,
AR_EEPROM_STATUS_DATA_BUSY |
AR_EEPROM_STATUS_DATA_PROT_ACCESS, 0,
AH_WAIT_TIMEOUT)) {
return false;
}
*data = MS(common-ops-read(ah, AR_EEPROM_STATUS_DATA),
AR_EEPROM_STATUS_DATA_VAL);
}
Also, in ar9300_eeprom_restore_internal it uses flash first, then falls back
to the eeprom read function, however elsewhere the 'eeprom' read function is
flash or eeprom depending on the pdata. If there is pdata, the eeprom read
function does not use real EEPROM data but through ath9_eeprom_read_pci
reads pdata-eeprom_data. If there is no pdata then that funtion actually
reads from EEPROM.
I guess this could be considered a design flaw if that was not the intended
result. i.e. if what we want is supposed to work, there is a bug.
Regards,
Daniel
Also, the change contains some useless whitespace mangling and uses the
wrong patch format (use make target/linux/refresh to clean that up).
- Felix
--
Daniel Dickinson PowerCloud Systems, Palo Alto, CA Senior Firmware Engineer (In
Canada: Senior Firmware Analyst)
signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] BCM Tag Problem: Re: [OpenWrt-Commits] r34230 - in trunk/target/linux: brcm63xx/patches-3.6 generic/patches-3.6
I think Kaloz missed the discussion of why this
was in generic not brcm63xx.
Regards,
Daniel
On 18/11/2012 4:22 AM, openwrt-comm...@openwrt.org wrote:
Author: kaloz
Date: 2012-11-18 10:22:38 +0100 (Sun, 18 Nov 2012)
New Revision: 34230
Added:
trunk/target/linux/brcm63xx/patches-3.6/260-move_bcm963xx_tag.patch
Removed:
trunk/target/linux/generic/patches-3.6/260-move_bcm963xx_tag.patch
Log:
target specific patches have nothing to do in generic..
Copied: trunk/target/linux/brcm63xx/patches-3.6/260-move_bcm963xx_tag.patch
(from rev 34224,
trunk/target/linux/generic/patches-3.6/260-move_bcm963xx_tag.patch)
===
--- trunk/target/linux/brcm63xx/patches-3.6/260-move_bcm963xx_tag.patch
(rev 0)
+++ trunk/target/linux/brcm63xx/patches-3.6/260-move_bcm963xx_tag.patch
2012-11-18 09:22:38 UTC (rev 34230)
@@ -0,0 +1,219 @@
+--- a/arch/mips/include/asm/mach-bcm63xx/bcm963xx_tag.h
/dev/null
+@@ -1,96 +0,0 @@
+-#ifndef __BCM963XX_TAG_H
+-#define __BCM963XX_TAG_H
+-
+-#define TAGVER_LEN 4 /* Length of Tag Version */
+-#define TAGLAYOUT_LEN 4 /* Length of FlashLayoutVer */
+-#define SIG1_LEN20 /* Company Signature 1 Length */
+-#define SIG2_LEN14 /* Company Signature 2 Length */
+-#define BOARDID_LEN 16 /* Length of BoardId */
+-#define ENDIANFLAG_LEN 2 /* Endian Flag Length */
+-#define CHIPID_LEN 6 /* Chip Id Length */
+-#define IMAGE_LEN 10 /* Length of Length Field */
+-#define ADDRESS_LEN 12 /* Length of Address field */
+-#define DUALFLAG_LEN2 /* Dual Image flag Length */
+-#define INACTIVEFLAG_LEN2 /* Inactie Flag Length */
+-#define RSASIG_LEN 20 /* Length of RSA Signature in tag */
+-#define TAGINFO1_LEN30 /* Length of vendor information
field1 in tag */
+-#define FLASHLAYOUTVER_LEN 4 /* Length of Flash Layout Version
String tag */
+-#define TAGINFO2_LEN16 /* Length of vendor information
field2 in tag */
+-#define ALTTAGINFO_LEN 54 /* Alternate length for vendor
information; Pirelli */
+-
+-#define NUM_PIRELLI 2
+-#define IMAGETAG_CRC_START 0x
+-
+-#define PIRELLI_BOARDS { \
+-AGPF-S0, \
+-DWV-S0, \
+-}
+-
+-/*
+- * The broadcom firmware assumes the rootfs starts the image,
+- * therefore uses the rootfs start (flash_image_address)
+- * to determine where to flash the image. Since we have the kernel first
+- * we have to give it the kernel address, but the crc uses the length
+- * associated with this address (root_length), which is added to the kernel
+- * length (kernel_length) to determine the length of image to flash and thus
+- * needs to be rootfs + deadcode (jffs2 EOF marker)
+-*/
+-
+-struct bcm_tag {
+-/* 0-3: Version of the image tag */
+-char tag_version[TAGVER_LEN];
+-/* 4-23: Company Line 1 */
+-char sig_1[SIG1_LEN];
+-/* 24-37: Company Line 2 */
+-char sig_2[SIG2_LEN];
+-/* 38-43: Chip this image is for */
+-char chip_id[CHIPID_LEN];
+-/* 44-59: Board name */
+-char board_id[BOARDID_LEN];
+-/* 60-61: Map endianness -- 1 BE 0 LE */
+-char big_endian[ENDIANFLAG_LEN];
+-/* 62-71: Total length of image */
+-char total_length[IMAGE_LEN];
+-/* 72-83: Address in memory of CFE */
+-char cfe__address[ADDRESS_LEN];
+-/* 84-93: Size of CFE */
+-char cfe_length[IMAGE_LEN];
+-/* 94-105: Address in memory of image start
+- * (kernel for OpenWRT, rootfs for stock firmware)
+- */
+-char flash_image_start[ADDRESS_LEN];
+-/* 106-115: Size of rootfs */
+-char root_length[IMAGE_LEN];
+-/* 116-127: Address in memory of kernel */
+-char kernel_address[ADDRESS_LEN];
+-/* 128-137: Size of kernel */
+-char kernel_length[IMAGE_LEN];
+-/* 138-139: Unused at the moment */
+-char dual_image[DUALFLAG_LEN];
+-/* 140-141: Unused at the moment */
+-char inactive_flag[INACTIVEFLAG_LEN];
+-/* 142-161: RSA Signature (not used; some vendors may use this) */
+-char rsa_signature[RSASIG_LEN];
+-/* 162-191: Compilation and related information (not used in OpenWrt) */
+-char information1[TAGINFO1_LEN];
+-/* 192-195: Version flash layout */
+-char flash_layout_ver[FLASHLAYOUTVER_LEN];
+-/* 196-199: kernel+rootfs CRC32 */
+-__u32 fskernel_crc;
+-/* 200-215: Unused except on Alice Gate where is is information */
+-char information2[TAGINFO2_LEN];
+-/* 216-219: CRC32 of image less imagetag (kernel for Alice Gate) */
+-__u32 image_crc;
+-/* 220-223: CRC32 of rootfs partition */
+-__u32 rootfs_crc;
+-/* 224-227: CRC32 of kernel partition */
+-__u32
Re: [OpenWrt-Devel] [PATCH] fix wget-ssl dependencies
I can't speak for the OP, but maybe because of an external toolchain? I know that some dependencies (which are real dependencies, and should be stated not just implied, even if normally not exposed by a build error) only show up when using external toolchains, or at least that's most even when I've seen a missing dependency come to light, particularly in core libraries. Regards, Daniel On 20/11/2012 4:20 PM, Luka Perkov wrote: On Tue, Nov 20, 2012 at 07:02:38PM +0100, michael-dev wrote: Index: net/wget/Makefile === --- net/wget/Makefile (Revision 34280) +++ net/wget/Makefile (Arbeitskopie) @@ -22,7 +22,7 @@ define Package/wget/Default SECTION:=net CATEGORY:=Network - DEPENDS:=+libpcre + DEPENDS:=+libpcre +libuuid SUBMENU:=File Transfer TITLE:=Non-interactive network downloader URL:=http://www.gnu.org/software/wget/index.html I don't think we need this. I have just tested wget with OpenWrt trunk on my kirkwood device. It works and compiles without this patch. Can you give us more details why you needed this ? Luka ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Daniel Dickinson PowerCloud Systems, Palo Alto, CA Senior Firmware Engineer (In Canada: Senior Firmware Analyst) signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Change Default IP?
Perhaps you're trying to set image configuration not preinit (i.e. the default for regular operation)? If so preinit is the wrong ip address. Regards, Daniel On 28/11/2012 7:21 PM, Weedy wrote: On 28/11/12 06:38 PM, John Lauro wrote: Is there a place to change the default IP for a firmware build? I tried setting under Image configuration - Preinit configuration options - IP address for preinit network messages, but that doesn't seem to work (not that I expected to, but it's the only config options I could find related to an IP address). Doing a search of my build tree, 192.168.1.1 seems to be embedded in several spots. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel Preinit configuration has always worked for me. You can use the more heavy handed $TOPDIR/files/etc/config/network if it is not working. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Daniel Dickinson PowerCloud Systems, Palo Alto, CA Senior Firmware Engineer (In Canada: Senior Firmware Analyst) signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Change Default IP?
Actually shouldn't matter. If using right config option (under Image options IRC) then there will be an uci-defaults file that runs on firstboot to set the ipaddr, which should occur after the defconfig configuration. At least that's the intended design; if the order of scripts is wrong then that's a bug. Regards, Daniel On 29/11/2012 5:21 PM, Hannu Nyman wrote: You mentioned later in the thread that you are building for wndr3800. That is the key info here. Due to complex switch port LED defintions, WNDR3700/3800 has a dedicated network file template that will be used: https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/base-files/etc/defconfig/wndr3700/network It has the section: config interface lan option ifname eth0.1 option type bridge option protostatic option ipaddr 192.168.1.1 option netmask 255.255.255.0 On 29.11.2012 1:38, John Lauro wrote: Is there a place to change the default IP for a firmware build? I tried setting under Image configuration - Preinit configuration options - IP address for preinit network messages, but that doesn't seem to work (not that I expected to, but it's the only config options I could find related to an IP address). Doing a search of my build tree, 192.168.1.1 seems to be embedded in several spots. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Daniel Dickinson PowerCloud Systems, Palo Alto, CA Senior Firmware Engineer (In Canada: Senior Firmware Analyst) signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Added default configurations for enabling wifi on omap4 by default
Hi dvrao, Generally in OpenWrt wireless is not configured automatically even with a default disable config. wifi detect is run to determine info about the wlan interface and set default parameters, but left disabled. It shouldn't be on the filesystem. Regards, Daniel On Fri, Jan 4, 2013 at 4:04 PM, dvrao dv...@gytechs.com wrote: On Saturday 05 January 2013 02:19 AM, Felix Fietkau wrote: On 2013-01-04 9:37 PM, dvrao wrote: On Saturday 05 January 2013 01:48 AM, Felix Fietkau wrote: On 2013-01-04 9:11 PM, dvrao wrote: Hi Imre Kaloz, With default configurations omap4(Pandaboard) WIFI is not working and Ethernet is in lan group. So added default configuration files of a working router(pandaboard)to change eth0 to wan and added working wlan configs. Signed-off-by: dvrao dv...@gytechs.com Index: target/linux/omap4/base-files/**etc/config/wireless ==**==** === --- target/linux/omap4/base-files/**etc/config/wireless(revision 0) +++ target/linux/omap4/base-files/**etc/config/wireless(revision 0) @@ -0,0 +1,19 @@ + +config wifi-device 'radio0' +option type 'mac80211' +option channel '11' +option path 'platform/omap/omap_hsmmc.4/**mmc_host/mmc1/mmc1:0001/mmc1:** 0001:2/wl12xx' +list ht_capab 'GF' +list ht_capab 'SHORT-GI-20' +list ht_capab 'RX-STBC1' +option txpower '25' +option hwmode '11g' +option country '00' + +config wifi-iface +option device 'radio0' +option mode 'ap' +option ssid 'Panda' +option encryption 'none' +option network 'lan' + The default configuration in OpenWrt intentionally does not enable unconfigured, unencrypted wifi by default, as it would expose access to LAN at a potentially inconvenient time. Please leave out /etc/config/wireless - Felix Hi Felix Fietkau, As Panda have one Ethernet(WAN mode) and one WIFI Module(LAN). To access the WEB UI of OpenWrt at least one LAN module must be enabled. As we have only WIFI module in LAN mode I enabled it by default to connect and configure initially (after we can enable security). Is there any way to connect and configure from WAN ? Maybe you should just leave Ethernet connected to the LAN. Let the user reconfigure it for WAN if necessary. - Felix Hi Felix Fietkau, Thanks for your support I have updated the patch. Please check. Signed-off-by: dvrao dv...@gytechs.com Index: target/linux/omap4/base-files/**etc/config/network ==**==**=== --- target/linux/omap4/base-files/**etc/config/network(revision 0) +++ target/linux/omap4/base-files/**etc/config/network(revision 0) @@ -0,0 +1,19 @@ + +config interface 'loopback' +option ifname 'lo' +option proto 'static' +option ipaddr '127.0.0.1' +option netmask '255.0.0.0' + +config interface 'lan' +option ifname 'eth0' +option type 'bridge' +option proto 'static' +option ipaddr '192.168.1.1' +option netmask '255.255.255.0' +option _orig_ifname 'eth0 radio0.network1' +option _orig_bridge 'true' + +config interface 'wan' +option proto 'dhcp' + Property changes on: target/linux/omap4/base-files/**etc/config/network __**__**___ Added: svn:executable + * Index: target/linux/omap4/base-files/**etc/config/luci ==**==**=== --- target/linux/omap4/base-files/**etc/config/luci(revision 0) +++ target/linux/omap4/base-files/**etc/config/luci(revision 0) @@ -0,0 +1,28 @@ + +config core 'main' +option lang 'auto' +option mediaurlbase '/luci-static/openwrt.org' +option resourcebase '/luci-static/resources' + +config extern 'flash_keep' +option uci '/etc/config/' +option dropbear '/etc/dropbear/' +option openvpn '/etc/openvpn/' +option passwd '/etc/passwd' +option opkg '/etc/opkg.conf' +option firewall '/etc/firewall.user' +option uploads '/lib/uci/upload/' + +config internal 'languages' +option en 'English' + +config internal 'sauth' +option sessionpath '/tmp/luci-sessions' +option sessiontime '3600' + +config internal 'ccache' +option enable '1' + +config internal 'themes' +option OpenWrt '/luci-static/openwrt.org' + Property changes on: target/linux/omap4/base-files/**etc/config/luci __**__**___ Added: svn:executable + * Index: target/linux/omap4/base-files/**etc/config/wireless ==**==**=== --- target/linux/omap4/base-files/**etc/config/wireless(revision 0) +++ target/linux/omap4/base-files/**etc/config/wireless(revision 0) @@ -0,0 +1,20 @@ + +config wifi-device 'radio0' +option type 'mac80211' +option
Re: [OpenWrt-Devel] compcache / ramzswap / zram / frontswap
On 13-01-04 04:23 PM, Damian Kaczkowski wrote: On 4 January 2013 21:52, Damian Kaczkowski damian.kaczkow...@gmail.comwrote: On 4 January 2013 18:25, Bastian Bittorf bitt...@bluebottle.com wrote: - MKSWAP and SWAPONOFF has to be a dependency, the old package compcache does this via DEPENDS:=@BUSYBOX_CONFIG_SWAPONOFF @BUSYBOX_CONFIG_MKSWAP I think better dependency would be: define KernelPackage/zram/config select BUSYBOX_CONFIG_MKSWAP if !PACKAGE_swap-utils select BUSYBOX_CONFIG_SWAPONOFF if !PACKAGE_swap-utils endef btw. Do we really need dependency for mkswap / swaponoff ? You can use any fs on zram disk not only swap (also your init script already checks for mkswap and swapon bins (but not swapoff btw.)). Maybe better would be what hauke proposed? - just set CONFIG_BUSYBOX_CONFIG_MKSWAP=y, CONFIG_BUSYBOX_CONFIG_SWAPONOFF=y as default config. Then also some other packages might benefit from this, eg. block-mount Actually swaponoff and mkswap were ditched by default due to size (block-mount is an optional package). Also depends that change busybox configuration are considered bad and it was an error to have them before (it creates incompatible bb builds depending on what packages are built). Better only have the util-linux dependency (if it's even needed). -- Daniel Dickinson PowerCloud Systems, Palo Alto, CA Senior Firmware Engineer (In Canada: Senior Firmware Analyst) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] D-Link DIR-600/601(Rev.A1) - Not preserving configurations
I use dir 601 a1 with no problem. Maybe the problem is the size check and you have too big an image to create a jffs2 partition. Regards, Daniel On 13-01-04 10:40 PM, HeXiLeD wrote: I have a few dir 601 A1 and built some images from attitude adjustment URL: svn://svn.openwrt.org/openwrt/branches/attitude_adjustment Repository Root: svn://svn.openwrt.org/openwrt Repository UUID: 3c298f89-4303-0410-b956-a3cf2f4a3e73 Revision: 35014 Node Kind: directory Schedule: normal Last Changed Author: nbd Last Changed Rev: 35003 Last Changed Date: 2013-01-03 15:03:14 -0500 (Thu, 03 Jan 2013) http://wiki.openwrt.org/toh/d-link/dir-600#supported.versions1 I now found out that all opkg packages installed or any configurations done are lost once the router reboots and the system reverts to the default build settings. Is this caused by the lack of jffs2 ? If so... it can be added to the wiki page as still not working. Are there any patches to solve this in trunk ? I also found another problem when set wireless to act as a wds server. It seems that mode wds does not work. The SSID does not even shows up on scan and some errors are outputted such as: radio0 (cfg033579): Invalid mode, ignored. Can anyone confirm these reports ? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Daniel Dickinson PowerCloud Systems, Palo Alto, CA Senior Firmware Engineer (In Canada: Senior Firmware Analyst) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH/RFC v2] add hardware id for TL-WDR4300v1 (IL) / regdomain issue
On Sun, 10 Mar 2013 20:03:29 +0200 Daniel Golle daniel.go...@gmail.com wrote: On 03/10/2013 07:52 PM, Bastian Bittorf wrote: * Daniel Golle daniel.go...@gmail.com [10.03.2013 18:00]: The default settings of the binaries on downloads.openwrt.org do *not* allow me to do that. And that's what I'm talking about. thats not true. OpenWrt defaults to regdomain US (hardcoded in the builts, because the regdomain is choosen during compiletime). so NACK. no such a thing as a hardcoded country code. initial regdomain is hinted from the value found in the EEPROM (and that may be 'US' for some hardware, despite the fact that it is sold outside of FCC-land). Many hardware vendors (e.g. wifi modules in laptops) even go as far as restricting their users to the *intersection* of all regdomains, i.e. you can't break the law *anywhere*. Using OpenWrt with the mac80211 stack (as it is the case when using the ath9k driver) means it works like this http://linuxwireless.org/en/developers/Regulatory/CRDA#Changing_regulatory_domains maybe someone else can confirm this? Actually, the default in the code is to use the EEPROM values if present, but if the EEPROM doesn't set a country code or is a particular value then it uses the default country code (US) embedded at compile time (the US default when there is not hardware country code may be specified by atheros in their datasheets, I'm not sure on that though). A lot of manufacturers have taken to using a default country code, and setting regulatory domain in firmware though because it gives more flexibility with their inventory (i.e. only have to change regular firmware not radio EEPROM value, if they want to ship to another country the hardware is certified for and has calibration data for). If the hardware vendor embeds the country code in the radio then ath9k will honour that, unless you hack on the ath/ath9k driver. people from e.g. country TN can use freq 5835 at 30 db which is completely forbidden there. as mentioned above, this would only be possible if your wifi card or in-flash EEPROM data initially permits the use of that frequency band. m'key? Actually you can hack ath9k, it's just not supported by anyone, and the developer's probably won'tsupport it in the case of ath9k because atheros has been very helpful and going against their atheros' to make sure the appropriate regulations for each country's regulatory body is met (not just US; US is just the default if there is no EEPROM code specifying country in the hardware) would make developing for ath9k much harder because they would stop supporting OpenWrt efforts, including providing datasheets and providing support to their clients who want to use openwrt. This isn't a matter of obeying the FCC and screw the rest of the world, it's trying to make sure that the appropriate regulations for the hardware's country are met. Unfortunately, as I have said a lot of device makers have taken to not including the country code, so the default country code gets used (and the default happens to be US). The danger is simply that people will flash OpenWrt and without even knowing start using frequency bands or TX-power-levels which they are not allowed to operate in their country. it's the same like block the word f*ck in the wordprocessor, because the government forbids it? ok, dont get me wrong, i overact a littly bit, but the hole thing upset's me... sorry, but this is really a different case. I concur, this isn't about what you say or write in private, for instance. EM interference is a public safety and communications issue (interfering with emergency frequencies or vital control systems is obviously bad, and even if it was just television signal, interfering with everyone else's television because *you* want better wifi is selfish at best; and messing with cell phones because you want wifi won't make you friends). Telecommunications regulations exist because otherwise it'd be like having a major metropolitan city with no road markings anywhere, and no signs, and no rules (image the walking zoo of major entertainment complex after an event, only with cars). It'd be a disaster. Regards, Daniel -- erno hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH/RFC v2] add hardware id for TL-WDR4300v1 (IL) / regdomain issue
Also, of note is that there are efforts underway to change the way regulatory compliance is met, so that the law is satisfied (and e.g atheros' need to comply) while addressing international concerns, however these efforts will take time and you will need to be patient. I'd recommend if you want to help and not just complain 'fix it *now*', the you should participate in linux-wireless development efforts. Regards, Daniel On Sun, 10 Mar 2013 14:41:22 -0400 Daniel Dickinson dan...@cshore.neomailbox.net wrote: On Sun, 10 Mar 2013 20:03:29 +0200 Daniel Golle daniel.go...@gmail.com wrote: On 03/10/2013 07:52 PM, Bastian Bittorf wrote: * Daniel Golle daniel.go...@gmail.com [10.03.2013 18:00]: The default settings of the binaries on downloads.openwrt.org do *not* allow me to do that. And that's what I'm talking about. thats not true. OpenWrt defaults to regdomain US (hardcoded in the builts, because the regdomain is choosen during compiletime). so NACK. no such a thing as a hardcoded country code. initial regdomain is hinted from the value found in the EEPROM (and that may be 'US' for some hardware, despite the fact that it is sold outside of FCC-land). Many hardware vendors (e.g. wifi modules in laptops) even go as far as restricting their users to the *intersection* of all regdomains, i.e. you can't break the law *anywhere*. Using OpenWrt with the mac80211 stack (as it is the case when using the ath9k driver) means it works like this http://linuxwireless.org/en/developers/Regulatory/CRDA#Changing_regulatory_domains maybe someone else can confirm this? Actually, the default in the code is to use the EEPROM values if present, but if the EEPROM doesn't set a country code or is a particular value then it uses the default country code (US) embedded at compile time (the US default when there is not hardware country code may be specified by atheros in their datasheets, I'm not sure on that though). A lot of manufacturers have taken to using a default country code, and setting regulatory domain in firmware though because it gives more flexibility with their inventory (i.e. only have to change regular firmware not radio EEPROM value, if they want to ship to another country the hardware is certified for and has calibration data for). If the hardware vendor embeds the country code in the radio then ath9k will honour that, unless you hack on the ath/ath9k driver. people from e.g. country TN can use freq 5835 at 30 db which is completely forbidden there. as mentioned above, this would only be possible if your wifi card or in-flash EEPROM data initially permits the use of that frequency band. m'key? Actually you can hack ath9k, it's just not supported by anyone, and the developer's probably won'tsupport it in the case of ath9k because atheros has been very helpful and going against their atheros' to make sure the appropriate regulations for each country's regulatory body is met (not just US; US is just the default if there is no EEPROM code specifying country in the hardware) would make developing for ath9k much harder because they would stop supporting OpenWrt efforts, including providing datasheets and providing support to their clients who want to use openwrt. This isn't a matter of obeying the FCC and screw the rest of the world, it's trying to make sure that the appropriate regulations for the hardware's country are met. Unfortunately, as I have said a lot of device makers have taken to not including the country code, so the default country code gets used (and the default happens to be US). The danger is simply that people will flash OpenWrt and without even knowing start using frequency bands or TX-power-levels which they are not allowed to operate in their country. it's the same like block the word f*ck in the wordprocessor, because the government forbids it? ok, dont get me wrong, i overact a littly bit, but the hole thing upset's me... sorry, but this is really a different case. I concur, this isn't about what you say or write in private, for instance. EM interference is a public safety and communications issue (interfering with emergency frequencies or vital control systems is obviously bad, and even if it was just television signal, interfering with everyone else's television because *you* want better wifi is selfish at best; and messing with cell phones because you want wifi won't make you friends). Telecommunications regulations exist because otherwise it'd be like having a major metropolitan city with no road markings anywhere, and no signs, and no rules (image the walking zoo of major entertainment complex after an event, only with cars). It'd be a disaster. Regards, Daniel -- erno hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment
Re: [OpenWrt-Devel] [PATCH/RFC v2] add hardware id for TL-WDR4300v1 (IL) / regdomain issue
On Sun, 10 Mar 2013 20:28:13 +0100 Bastian Bittorf bitt...@bluebottle.com wrote: * Daniel Dickinson dan...@cshore.neomailbox.net [10.03.2013 19:57]: Actually, the default in the code is to use the EEPROM values if present, but if the EEPROM doesn't set a country code or to be clear: during compile-time, a description is loaded which values are allowed for each country: http://git.kernel.org/?p=linux/kernel/git/linville/wireless-regdb.git;a=blob_plain;f=db.txt;hb=HEAD even if those values are changing (and they do!) you have e device which needs a reflash to get the new values, so in the EEPROM is just the country set and the software/driver knows what to do. e.g. what we make, is to include a changed regdb during compiletime. (but ofcourse respect the law) it's the same like block the word f*ck in the wordprocessor, because the government forbids it? ok, dont get me wrong, i overact a littly bit, but the hole thing upset's me... sorry, but this is really a different case. I concur, this isn't about what you say or write in private, for ok, this was a bad example. instance. EM interference is a public safety and communications issue (interfering with emergency frequencies or vital control systems is obviously bad, and even if it was just television signal, interfering with everyone else's television because *you* want better wifi is selfish at best; and messing with cell phones because you want wifi won't make you friends). Telecommunications regulations exist because otherwise it'd be like it's not about breaking the law (no discussion about that needed here) it's about using the values you are allowed, e.g. using channel 12,13 in germany - but all the EEPROM are for US. you posted some screenshots of the original tplink-firmware for Israel: they made nearly everything wrong for the user. I'm afraid you've confused me with someone else. I posted no such thing. Also I looked at the forum link Daniel Golle mentions in his followup to this message, and it is talking about exactly breaking (Israeli) law in Israel (the whole reason they don't want to use the default firmware is that they want to use channels that (they at least seem to believe) are 'not allowed by the government here [Israel]'). I.e. they want to break the law. I agree it makes things hard for legitimate users but the developers cannot simply let anyone do anything and expect to continue to get information and support from US-based chipset companies that take a dim view of assisting breaking the law, or not putting adequate safeguards in place to prevent non-knowledgeable/caring users from causing EM interference (actually most governments are the same way, in case you haven't noticed). In addition developers need to know that their not going to be held resposible for other developers not caring about their country's laws, unless OpenWrt is willing to lose all developers from the US and Canada (which has similar laws). Basically part of the reason there is an effort underway to improve the means by which regulatory enforcement is done is that all developers need to be able to tell regulators of their country that their countries regulations are not being thwarted by a project they work on. The original intent of atheros was that the EEPROM country code would be used to differentiate countries and this mechanism was the mechanism coded for. Device manufacturers don't like the scheme, however, because it causes inventory issues (you have to have devices that are specific to a country), so a new mechanism is needed, however it takes time to design and develop something that will satisfy the law, chipset manufacturers interpretations of what they need to do to obey the law, odm interpretation of what they need to do to satisfy the chip vendor, and linux developers and lastly users (sorry but open source is a codocracy; you write or pay for the writing the code, it's your decision; if you're user-oriented, users get a say, but it's the people who do (and may be legally liable) who make the decisions). Regards, Daniel Regards, Daniel bye, bastian. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- erno hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] GitHub repo with collectd5 package for AA
Hi all, FYI, I have created a GitHub repo with a 'collectd5' package for Attitude Adjustment, which adds collectd 5.0.3 to AA (I plan on doing a trunk port at some point too). Add src-git cshore_aa git://github.com/cshore/openwrt-aa-packages.git and update your feeds if you want to build it / try it out. Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] network: update state file even when bringing down interfaces
What happens if two or more hotplug events trigger essentially
simultaneously (can happen)? i.e. how do you prevent multiple processes
writing out of order (i.e. order is not guaranteed)?
Regards,
Daniel
On 13-06-28 09:55 AM, Enrico Mioso wrote:
This patch makes the network status file in /tmp/ consistent, so that
when an interface goes down, any script parsing the file can see it!
This can be a pretty good alternative to json when you need a VERY
small script.
Index:
package/network/config/netifd/files/etc/hotplug.d/iface/00-netstate
===
---
package/network/config/netifd/files/etc/hotplug.d/iface/00-netstate
(revision 37055)
+++
package/network/config/netifd/files/etc/hotplug.d/iface/00-netstate
(working copy)
@@ -6,3 +6,7 @@
uci_toggle_state network $INTERFACE ifname $DEVICE
}
}
+
+[ ifdown = $ACTION ] {
+uci_toggle_state network $INTERFACE up 0
+}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
--
Daniel Dickinson PowerCloud Systems, Palo Alto, CA Senior Firmware
Engineer (In Canada: Senior Firmware Analyst)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] DFS ath9k
Hi, Is there any progress on DFS for ath9k/mac80211? Also what support is there presently? (Is it still a case of some kernel hooks, but no userspace; and is the kernel support at least complete?) I'm not asking for estimated availability, just what exists and if there is forward motion. Regards, Daniel -- Daniel Dickinson PowerCloud Systems, Palo Alto, CA Senior Firmware Engineer (In Canada: Senior Firmware Analyst) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] DFS ath9k
Awesome! Thanks for the info. Regards, Daniel On 13-08-02 01:38 AM, Dirk Neukirchen wrote: I am under the impression that DFS with ath9k is working in trunk (3.10.x). Hardware: TP-Link WDR3600 (AR9582) iw phy phy0 info prints for example * 5580 MHz [116] (19.0 dBm) (radar detection) DFS state: usable (for 2779417 sec) * 5700 MHz [140] (15.0 dBm) (radar detection) DFS state: usable (for 2779417 sec) or (switched region): * 5680 MHz [136] (15.0 dBm) (radar detection) DFS state: usable (for 466 sec) * 5700 MHz [140] (15.0 dBm) (radar detection) DFS state: usable (for 466 sec) * 5745 MHz [149] (disabled) wireless drivers are: Loading modules backported from Linux version master-2013-06-27-0-gdcfa6d5 Backport generated by backports.git backports-20130617-4-ge3220f5 -- Daniel Dickinson PowerCloud Systems, Palo Alto, CA Senior Firmware Engineer (In Canada: Senior Firmware Analyst) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] block-mount overrides /etc/config/fstab as defined by target
On Wed, 30 Mar 2011 19:14:42 +0200 Ithamar R. Adema ithamar.ad...@team-embedded.nl wrote: Hello, After a recent upgrade to latest Backfire I bumped into an interesting problem. If a target has a /etc/config/fstab file in its base-files (target/linux/$(TARGET)/base-files/etc/config/fstab) and has block-mount as package enabled, it will get the fstab file from the block-mount package instead of the one under target/linux. Ok, let me see if I understand what you are seeing first. When you say block-mount as package you mean that it is NOT installed into the image, but rather as a separate package to be installed later? This looks to me like a regression, as first of all, it didn't happen in earlier backfire versions, and second, it seems pretty unlogical. I can work around it for now by removed the 'conffiles' definition from the block-mount package, so it won't be installed as part of the package, but I agree that isn't the proper fix. Do you also remove the $(INTALL_DATA) ./files/fstab.config $(1)/etc/config/fstab ? If not then the file should still be installed regardless of the conffiles. AFAIK conffiles just says don't overwrite if it already exists. Regards, Daniel -- erno hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is. GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org 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] [OpenWrt-Tickets] [OpenWrt] #9143: Kernel oops in preinit after erasing jffs2 partition on ramips rt305x
So I think I have identified the problem... I just don't have a solution yet. Thank you for the analysis. Now to try to find time to work on it Regards Daniel -- erno hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is. GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org 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] block-mount overrides /etc/config/fstab as defined by target
On Thu, 31 Mar 2011 20:09:07 +0200 Ithamar R. Adema ithamar.ad...@team-embedded.nl wrote: Do you also remove the $(INTALL_DATA) ./files/fstab.config $(1)/etc/config/fstab ? If not then the file should still be installed regardless of the conffiles. AFAIK conffiles just says don't overwrite if it already exists. No, I had to remove the fstab install line as well, to get it to behave. I thought I hadn't when I wrote the mail, hence the confusion. For some reason, the fstab of block-mount get precedence over any other. I can hardly imagine this is wanted behavior ;-) Actually this is normal. Order is base-files, then target/base-files, then packages. It's doing target/base-files/etc/config/fstab that is wrong because block-mount is not base-files. It looks like a target-specific hack to block-mount is needed, because there is no mechanism for target-specific overrides to packages other than base-files. -- erno hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is. GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org 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] [PROPOSAL] growing OpenWrt devel team
On Mon, 28 Mar 2011 19:44:31 +0200 Gregers Petersen g...@openwrt.org wrote: Dear All I've been following the discussion and would like to offer to organize an irc meeting on -devel - to discuss this issue, and together generate a model for how to change things to the better. I would like to suggest that everyone joins -devel on irc this next sunday at 19:00 UTC to discuss the topic. Sorry, I'm going to be out of town at that time (3pm -0400 GMT). -- erno hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is. GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org 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] block-mount overrides /etc/config/fstab as defined by target
On Fri, 01 Apr 2011 12:43:43 +0200 Ithamar R. Adema ithamar.ad...@team-embedded.nl wrote: Hi, On Thu, 2011-03-31 at 15:05 -0400, Daniel Dickinson wrote: Actually this is normal. Order is base-files, then target/base-files, then packages. It's doing target/base-files/etc/config/fstab that is wrong because block-mount is not base-files. It looks like a target-specific hack to block-mount is needed, because there is no mechanism for target-specific overrides to packages other than base-files. Ok, in that case, I cannot picture why there is an fstab included in block-mount, as it is inherently target specific, and without a way to override it I can only imagine it causing more pain then it is worth to have a template installed by default. Regards, How is it 'inherently target specific' ? It varies from device to device, but even within a target it differs, so we pick what is most likely to be used (/dev/sdXX). It works for most people, and it's easy enough to change. Extroot or external storage isn't something that belongs as an enabled by default option anyway. This doesn't deal with mounting the rootfs for something that needs it to boot (for that you need USB built into the kernel). Regards, Daniel -- erno hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is. GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org 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 process
On Fri, 01 Apr 2011 19:31:41 +0200 Gregers Petersen g...@openwrt.org wrote: Dear all I promised to post an agenda for the patch process meeting sunday on irc -devel @ 19:00 UTC. The generel discussion has concerned two central points. first, how is the patch submission process in reality working? Secondly, in what way does an individual become an OpenWrt developer? Patch submission; several individuals have voiced the issue that patches submitted to the mailing-list, or in Trac, have been un-acknowledged. There has been no reply from any of the current developers, and the submitter wonders what is wrong (is the patch itself flawed, is the patch-process not working etc.) Becoming a developer; is a topic of concern. The general position of the OpenWrt developers is the well-known: Do good work and you will gain access right to the repository/Trac. I can't be there, so I'll post my thoughts here. Agenda: 1. Patch process: - is the current patch process understandable? - what other ways of doing things are available? - is better documentation needed? - OpenWrt ombudsmand? Some problems with the patch process is that we get patches for targets that only some developers know enough to make intelligent comments on the patch. In addition, the patches are of varying quality and utility and the developers (like myself) are busy with full-time jobs. That means we have to verify every patch before we commit it, and we don't have much time to do that. Blame the people who submit patches they haven't even bothered to compile. 2. Developer: - how to better the inclusion of new committers? This I don't know about...I think the inclusion of new committers is primarily up to Kaloz, at least I've never been asked about it (though I am a relatively new dev). - mentor-system? 3. Other things? Regards, Daniel -- erno hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is. GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org 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] bcm63xx: Move the OpenWrt rootfs length field
On Mon, 7 Mar 2011 21:15:03 +0100 Jonas Gorski jonas.gorski+open...@gmail.com wrote: Er, I've forgotten. Has this been applied yet? -- erno hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is. GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org 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] bcm63xx: Move the OpenWrt rootfs length field
Hi, Did Florian apply this already? If not could I get you to redo the command line parsing changes via editing .ggo file and regenerating the C files from there. That is the preferred way for code changes. The only reason we include the .c and .h for the parsing is that we didn't want to make gengetopt a build dependency. Regards, Daniel 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] block-mount add missing directory
On Sun, 20 Mar 2011 21:04:06 +0100 Maarten Bezemer m.m.beze...@utwente.nl wrote: Fixes warning of missing /lib/functions/fsck directory during boot. Happens when no scripts are installed in this directory (ie when e2fsck is not enabled) --- Signed-of-by: Maarten Bezemer Committed (after update to new block-mount) r26468. -- erno hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is. GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org 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] geos: uci-defaults updates
On Thu, 14 Apr 2011 22:05:27 -0600 Philip Prindeville philipp_s...@redfish-solutions.com wrote: Punch firewall holes for ISAKMP (udp port 500) and IPsec ESP. Set system.foreground to 1 to force scripts to complete before starting console shell. Signed-off-by: Philip Prindeville phil...@redfish-solutions.com --- I don't think making ISAKMP (IPSec) default firewall for only one platform makes sense. Either it makes sense for the firewall in general, or it shouldn't be in a default image IMO. Jo, any comments? Also system.foreground=1 is another thing that should be a debugging optoin, not a general use option. -- erno hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is. GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org 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] geos: Add PC speaker to kernel definitions
On Thu, 14 Apr 2011 20:31:14 -0600 Philip Prindeville philipp_s...@redfish-solutions.com wrote: Add the PC speaker back to the Geos platform. Signed-off-by: Philip Prindeville phil...@redfish-solutions.com --- Index: target/linux/x86/geos/config-default === --- target/linux/x86/geos/config-default(revision 26677) +++ target/linux/x86/geos/config-default(working copy) @@ -13,7 +13,7 @@ CONFIG_MGEODE_LX=y # CONFIG_MOUSE_PS2 is not set # CONFIG_PCIEPORTBUS is not set -# CONFIG_PCSPKR_PLATFORM is not set +CONFIG_PCSPKR_PLATFORM=y CONFIG_PROCESSOR_SELECT=y # CONFIG_SCx200 is not set # CONFIG_SERIO_I8042 is not set ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel Committed. -- erno hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is. GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org 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] Problem: Cannot satisfy the dependencies for ... during installation into image
On Fri, 06 May 2011 10:09:49 +0200 Ithamar R. Adema ithamar.ad...@team-embedded.nl wrote: On Thu, 2011-05-05 at 16:49 -0600, Philip Prindeville wrote: I agree that user files should take precedence over canned release files (actually, I thought this was the case?). This used to be the cause, but broken a while ago. See this[1] disucssion for previous discussion on basically the same problem. Ithamar. [1]: https://lists.openwrt.org/pipermail/openwrt-devel/2011-March/010191.html Which reminds me, which target is the offending one with a per-target fstab (which I believe is wrong, unless the target can only ever possibly have a single known USB device (i.e. internal USB device only, rather than USB host port))? Also, I want to take a look at the fstab and see how it differs from the default to see if it truly a platform-specific config or just that the platform dev happens to prefer a different config. If it's a true target-specific one then the thing to do is modify the block-mount makefile to use a different config depending on the target. If not then I need to discuss the issue with the platform maintainer. -- erno hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is. GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org 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] How to ensure that Tor is at the latest version?
On Thu, 21 Apr 2011 01:14:40 -0700 Jacob Appelbaum ja...@appelbaum.net wrote: Hi, I've had a report of a user installing Tor (package 'tor') on OpenWRT (backfire) and they appear to have a much older version than what is currently in svn. Why is this happening? Is there a way to ensure that users have the current stable version of Tor as it appears in (the OpenWRT) svn? Unfortunately uClibc doesn't have a stable ABI so packages built for trunk or newer versions of backfire don't necessarily work with older versions of backfire or trunk (segfaults etc). OpenWRT doesn't have the resources (due to openwrt being almost exclusively a volunteer project and developers tending to be busy with paid work unrelated to openwrt) to rebuild the newer packages tree against older versions of the core tree, so once a release is made packages are not updated until the core and packages together are updates. If you want to use stock OpenWRT you can be relatively current with the latest rc of the current openwrt release (currently 10.03.1~rc5) If you want to ensure your package specifically is at the latest version for users, I would provide a feed and a packages repository where you provide builds of new packages against the old core you are supporting. Regards, Daniel -- erno hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is. GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org 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] [OpenWrt] #6920: Siemens SL2-141 Support
On Fri, 13 May 2011 14:47:38 - OpenWrt openwrt-devel@lists.openwrt.org wrote: #6920: Siemens SL2-141 Support ---+ Reporter: ironmaiden666@…| Owner: cshore Type: task | Status: accepted Priority: response-needed| Milestone: Attitude Adjustment (trunk) Component: other | Version: Trunk Keywords: | ---+ Comment(by codi): Replying to [comment:21 cshore]: Could anyone who is able to risk bricking their router when I get them to test for me let me know? I don't have this hardware to test, and I am ashamed to admit I forgot this ticket. I bought a second device just for this case. It has the normal Firmware on it, not the one from Alice. Please bug me in about a week (sorry very busy right now), but if you don't send an new email it's liable this one will be forgotten. -- erno hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is. GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org 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/1] mac80211: atomic64_read() already present on x86 processors
On Tue, 12 Jul 2011 22:47:23 -0700 Philip Prindeville philipp_s...@redfish-solutions.com wrote: This is a fix to a regression introduced in r27572. Redux: thanks, Daniel, for pointing out the ifndef CONFIG_GENERIC_ATOMIC64 was backwards in sense. Er, no, I meant that it was always true for x86 because x86 does other 32-bit vs 64-bit stuff. The previous fix was right. -- erno hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is. GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org 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] whole_filesystem extroot not working with backfire-rc5-testing
On Mon, 27 Jun 2011 16:30:05 -0400 Brian J. Murrell br...@interlinx.bc.ca wrote: I've created a whole_filesystem style extroot with the following commands: # mkfs.ext3 /dev/sda1 # mount /dev/sda1 /mnt # mkdir -p /tmp/cproot # mount --bind / /tmp/cproot # tar -C /tmp/cproot -cvf - . | tar -C /mnt -xf - # umount /tmp/cproot # umount /mnt I've installed kmod-usb-storage kmod-fs-ext3 block-mount block-extroot block-hotplug e2fsprogs and created an /etc/config/fstab: config global automount option from_fstab 1 option anon_mount 1 config global autoswap option from_fstab 1 option anon_swap 0 config mount option target /mnt option device /dev/sda1 option fstype ext3 option options rw,sync option enabled 1 option enabled_fsck 1 option is_rootfs 1 and yet the extroot is not being mounted at /, but rather /mnt (this was the syntax prior to my upgrading to RC5). If I change the target to /, the mount table says it is mounted, but when I use df I see the same usage values as the /dev/root 2.1M 2.1M 0 100% /rom mini_fo:/overlay 2.1M 2.1M 0 100% / pair and files in / are from prior to the mount, not what is on /dev/sda1 Is this known to be broken or working in RC5? Cheers, b. Sorry I got busy after I made the changes to trunk and forgot to backport them to backfire. The whole filesystem style extroot is a feature available in backfire at this time. I'm hesitant to backport for 10.03.1 now, unless there will be an rc6, because it could break things to backport those changes, and I'd like more testing than people svn'ing the backire tree between now and the final release. -- erno hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is. GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC] Boot/Preinit/Init Requirements (for the init/preinit that will be coming)
Hi all,
I've been working on the requirements specification for
boot/preinit/init to try to illuminate what preinit/init has to be able
to do to be feature complete compared to the current version, plus the
new features we want to have. I was originally looking for a way to
reduce what preinit does, but the fundamental limitation of not being
able to have open references on the old rootfs after pivot to new
rootfs, of we want *really* unmount it, means that the rootfs mount
logic must happen before we start doing hotplug and running the
initscripts, and preinit really doesn't do all that much that isn't
directly related to these three:
* failsafe
* mount target rootfs (either remounting root r/w for all_jffs2/ext4,
mounting jffs2 rootfs_data mtd parttion for squashfs, or an external
root)
* start init
If anyone has any great ideas on how to get a rootfs without wasting
space (so not initramfs or kexec as the default) or leaving open
references after pivot (can this be avoided doing mount root in init?),
I'd love to hear them, but while reducing what has to be done in
preinit, I'd love to hear it.
This is article is on the wiki at :
http://wiki.openwrt.org/doc/techref/requirements.boot.process
== Boot/Init Requirements ==
This article attempts to state what the initscripts must and should do
for the new init system being developed for OpenWrt. The goal is to
deal with the race conditions that currently can occur, without losing
current functionality.
= Boot/Preinit =
The Boot process currently consists of the kernel bootstrap (not
discussed here), preinit, and init. Preinit takes care of things that
init can't function without, while init is responsible for starting up
the rest of the system.
On a Debian desktop system there is an analogue to preinit, which uses
initramfs to bring up the system enough to the point init can operate.
Unfortunately initramfs is not an option on openwrt because it wastes
too much space. The binaries and scripts in an initramfs cannot be
retained for use in the booted system, unless they are copied to RAM
(tmpfs) (if anyone know otherwise and can point out how, please contact
the devs), which is why preinit exists.
Preinit looks to linux like the final boot stage to init on the
rootfs. Preinit then mounts the root file system, does ''pivot_root''
to the rootfs, and then use the real init to replace itself. Basically
it transforms intself into the 'real' init and rootfs.
Goals
* Reduce preinit as much as possible so that init does most of the
work
* Maintain failsafe ability, so that if mounting, etc, rootfs fails,
or init makes system inaccessible, that there is a way to get into
the device and fix it.
* Not start hotplug at all in preinit ... for that matter no
processes except the real init should cross the preinit/init
boundary.
* Be configurable...it should be possible to configure rootfs mount,
init start and anything else that can happen after the jffs2 is
mounted (and therefore a writable config is available)
* LED and network message functionality should be available to
switchinit (which runs a script to shutdown process and make some
other process than the current init PID 1, e.g. for doing a safer
sysupgrade, and firstboot ('factory reset'))
* Support /opt type deployments as well as extroot (that is, extra
packages on /opt rather than by replacing the jffs2 rootfs)
* No open file descriptors/references on the old rootfs when init is
executed on the target rootfs (this is why we don't just
mount/pivot in init).
=== Notes ===
* JFFS2 Formatting must be done on a fully booted system, because on
some routers (like the Fon with NOR flash), formatting takes a
significant amount of time during which the router would be
unavailable for use). That means preinit can't be where the
formatting happens.
* Ideally the firstboot script will take the router back to state
exactly like after flashing without configuration saved), including
the needs for formatting jffs2
* Restoring the configuration needs to be done after the rootfs is
mounted, but before most configuration is used (most configuration
is used in init or init-launched hotplug).
* Saving the configuration should save the jffs2 (for squashfs)/or
boot rootfs config not the config on external root. This is
because the external root will still be available on the external
storage after flashing, but the internal (jff2 or other boot
rootfs) won't.
Must-do's
- Allow failsafe
- If initramfs, do initramfs, skip rest of this list
- For Squashfs: Mount jffs2 (if already formatted)
- For External Block: Mount swap (so fsck has enough memory) if
present
- For External Block: Mount rootfs (checking first if fsck available)
or tmpfs (if no rootfs yet)
- For External Block: Mount marked fses before init (e.g. for
deployments where
[OpenWrt-Devel] [Alix2] [Geode] [Geos] Note to Philip Prindeville
Hi Phillip, Could you please stop sending millions of small patches on the assumption that small == trivial. A trivial patch is a patch that is complete in and of itself and doesn't need more patches before or after to finish solving whatever problem it is related to, and is one-time thing that only rarely is possible. You're working on platform support for Geode platforms such as Geos and Alix2, so could you please try to get platform support fully integrated and working in a patch or patch series, and then submit the completed (or to the best of your genuine knowledge complete) patch or patch series, rather than bombarding the list with patches and getting impatient because your patches aren't applied quickly. I realize that mistakes do occur, but I'd like to see some sign you're actually making an effort to minimize unnecessary work for us, the devs, rather than just hacking on trunk with us as intermediaries. It would also make clearer what you are trying to achieve so we can best see how to integrate that with the OpenWrt philosophy and existing platforms and userbase. While I personally am interested in seeing a solution to the problem of meeting multiple embedded needs, it can't come at the expense of the core platforms and userbase. (The core of openwrt is wireless routers and access points based on commodity hardware). It would help if you told us your destination and ideas you had for a shared space with consumer hardware, and if you demonstrated that you weren't just doing many small, incomplete, and untested hacks. For platform support, I personally would like to see what you think is a (fairly) complete solution, and then work with us on the things that need to changed. That's how I got started with extroot. I didn't submit it as a series of tiny edits, but as a complete solutions. There were some more subtle bugs, and I've refactored since then, but on the whole it worked, and filled a much-requested feature in a way that fit into OpenWrt. Also, if you want me to go over some things I've learned about how to setup the builds system and image generator and environments so that I can build images based on openwrt, but with different use cases than the default openwrt (and hence different packages, configs, etc), without having to change openwrt trunk/backfire to git my goals, I should write it up on the wiki anyway. Understanding how to build images (easily) that include features/configuration that aren't appropriate as OpenWrt defaults (e.g. trunk/backfire) could help ease some tension you have with the openwrt defaults I think. (for example including large packages like openssl in the default configuration isn't necessary; you can achieve that goal with image generator and an appropriate script, without a lot of effort). Regards, Daniel -- erno hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is. GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org 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] [OpenWrt] #4998: Compilation for sablevm
On Tue, 28 Apr 2009 10:57:04 - OpenWrt openwrt-devel@lists.openwrt.org wrote: #4998: Compilation for sablevm -+-- Reporter: Daniel Dickinson csh...@… | Owner: developers Type: defect | Status: closed Priority: normal | Milestone: Kamikaze Component: packages| Version: Resolution: worksforme |Keywords: -+-- Changes (by florian): * status: new = closed * resolution: = worksforme Comment: I cannot reproduce this issue here with jikes 1.22 (Debian lenny). Okay, I'll try with jikes; I only have gcj and openjdk on my system. This should perhaps be documented somewhere like a README for build requirements for at the root of the source tree. -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Whence the wiki; if admin has no time I can do it
I'm a little frustrated by the wiki situation, as are others, and I want to get something up and running. If the person who was supposed to do doesn't have the time to take care of it after all, I am willing to do it, but something has to happen and soon. Months plural now applies to the wiki downtime. Regards, Daniel -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com 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] Status of X-WRT and Luci feeds
On Sun, 14 Jun 2009 17:03:19 -0500 David A. Bandel david.ban...@gmail.com wrote: Folks, Not sure what I've done, but the x-wrt (and luci) feeds don't seem to work. I can get to http://x-wrt.googlecode.com/svn/trunk/package in my browser, as found in the feeds.conf.default file, but when I run scripts/feeds update -a, I get: Updating feed 'xwrt' from 'http://x-wrt.googlecode.com/svn/trunk/package' ... svn: OPTIONS of 'http://x-wrt.googlecode.com/svn/trunk/package': could not connect to server (http://x-wrt.googlecode.com) failed. Not sure what I've done wrong, but luci gives me the same error. Any svn experts with ideas? TIA, David A. Bandel If you're using Debian Squeeze it's a bug in squeeze. You need libneon from unstable. -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://www.bmts.com/~cshore signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Ping Re: RFC: LuCI Web Interface Image Format
No one seems to have responded to this, and I'd like to start working on it next week. If developers could think about this and comment, it would be appreciated. On Fri, 12 Jun 2009 18:37:42 -0400 Daniel Dickinson crazycsh...@gmail.com (by way of Daniel Dickinson crazycsh...@gmail.com wrote: I would like to suggest an improvement I would implement for the LuCI firmware update. Current the LuCI update is pretty basic; it calculates the md5sum of the image and if you want to make sure it transferred correclty you have to find the md5sums file and manual verify the sum. This is awkward and not very effective, and it also misses the class of error in which the image is corrupt on the host machine. I would therefore like to propose that all targets implement the creation of an additional firmware image that is targeted at upgrades of OpenWRT from OpenWRT (using LuCI). Currently the firmware images are all designed to be flashed using vendor methods, and upgrading from within OpenWRT is a poor cousin. I think we need a firmware image that can be used to verify the validity of the image before flashing it, that is unified for all routers supported by OpenWRT. We need: * An MD5SUM or SHA1SUM of the image (that is, the portion that will be writen to the flash or other target device), so that the validity of the image can be verified. * An MD5SUM or SHA1SUM of the header (to ensure none of the header information has been corrupted, since it will determine how we flash the device) * An indicator the the method and/or parameters needed to flash the image (since different routers probably have different requirements); for example 'mtd linux' * For boards that need it; the starting offset of the kernel, the length of the kernel, the starting offset of the rootfs, and the length of the rootfs * Immediately before the start of the rootfs (in the padding between kernel and rootfs) (i.e. at the tail end of the kernel mtd partition for flash devices), there should be a space for vendors to place data, that, if non-null, must match what is already on the router. This allows a vendor who is a service provider to create firmware images for specific clients, and to ensure they can't accidentally flash the wrong router with the wrong image. * In the same location should probably also be an indication of which router this is, so that flashing the wrong router can be prevented. * Some vendors may want a signed header (with a public/private key) so that web interface flashing can only be done with approved images (serial console/tftp flashing is of course still open for anything, but in the service provider scenario the case would never be opened so serial console flashing is not an issue). This header would not be present on the router after flashing (but the flash safety features between kernel and rootfs would), it is only to ensure that the image flashed is not corrupt and is valid for this router. Ideally the between kernel+rootfs portion of the image would also be generated for the vendor flash methods (e.g. CFE, TFTP, Vendor web interface) so that upgrades via LuCI have the safety features available before the first upgrade (i.e. once OpenWRT is on the router). I'd like to implement this for brcm63xx soon, so any comments would be appreciated. Thank you, Daniel -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://www.bmts.com/~cshore 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] Ping Re: RFC: LuCI Web Interface Image Format
On Wed, 17 Jun 2009 23:08:17 +0200 Felix Fietkau n...@openwrt.org wrote: My plan for the unified format is to keep the on-flash format the same as the input format. In the long run, I don't want any unpacking to be done in sysupgrade or the web interface. The structure is roughly like this: [second stage loader][environment][kernel][rootfs] Ok, here's my question. The brcm-63xx *require* a Broadcom format imagetag at the start of the flash image (on flash and for CFE upgrades), and won't load without it. Do you mean to keep this imagetag and have the [second stage loader][environment][kernel][rootfs] all in the kernel partition (as far as the CFE is concerned; for the OpenWRT obviously the partitions would be determined by the environment) ? Also, how does the second stage loader compare to the kernel? I ask because I have run across a router for which the CFE verifies the CRC of the kernel after it has been decompressed. Would the unified format be a problem for this router? Also, when it comes to decompression, do the 63xx routers have the CFE do the decompression or is it a loader? I ask because I know that the kernel has to be compressed with specific lzma parameters for it to work with the CFE and that indicates to me that it's not an arbitrary loader that's doing the unpacking, but rather the CFE. Or do you run the loader *after* un-lzma by the CFE? -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://www.bmts.com/~cshore 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] [RFC] mklibs.py integration
On Sat, 25 Jul 2009 12:25:20 +0200 Florian Fainelli flor...@openwrt.org wrote: Hi all, Please find below a proof-of-concept of the mklibs.py reduction integration in OpenWrt. I have not been able to strip the uClibc loader more than 4KB out of 28KB (original size) but it might significantly better results with more softare installed in the rootfs. --- Index: Config.in Doesn't mklibs.py remove portions of a library that are unused? Wouldn't that mean that fewer programs would result in more removal (due to more unused bits). Or do you strip all libraries and not just uClibc? Regards, Daniel -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://www.bmts.com/~cshore 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] Serial console failsafe and failsafe enhancements; Ticket #5516
I've attached a patch, repeated here, to ticket #5516 which fixes the
issue there, which is that it is impossible to enter failsafe mode from
the serial console because the stated 'Enter CTRL-C to enter failsafe
mode' doesn't work.
The fact is that CTRL-C to enter failsafe can't work because SIGINT is
not generated by Ctrl-C while on /dev/console in single user mode in
Linux. Ever. That is because there is no job control on /dev/console in
single user mode. It's just a fact of life.
Needs testing to ensure that reset button entry of failsafe still works
(SIGUSR1) and that other means of generating SIGINT still enter failsafe
mode.
Also adds a 3rd_party failsafe script option which is useful for
service providers who want to use OpenWRT and have special non-generic
customization needs. Like the project I'm working on.
And finally; would it be possible to get svn commit access and what are
the policies for using it (I will do my best not to step on anyone's
toes or break anything, for instance). I think Florian and Jo will
vouch for me, but I haven't asked them yet.
I do have commit access to LuCI's svn thanks to Jo, already.
--
And that's my crabbing done for the day. Got it out of the way early,
now I have the rest of the afternoon to sniff fragrant tea-roses or
strangle cute bunnies or something. -- Michael Devore
GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org
The C Shore (Daniel Dickinson's Website) http://www.bmts.com/~cshore
Index: package/base-files/files/etc/preinit
===
--- package/base-files/files/etc/preinit (revision 17031)
+++ package/base-files/files/etc/preinit (working copy)
@@ -1,6 +1,6 @@
#!/bin/sh
# Copyright (C) 2006 OpenWrt.org
-export PATH=/bin:/sbin:/usr/bin:/usr/sbin
+export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
. /etc/diag.sh
failsafe_ip() {
@@ -8,12 +8,14 @@
}
failsafe() {
+ echo - enter failsafe -
[ -n $ifname ] grep $ifname /proc/net/dev /dev/null {
failsafe_ip
netmsg 192.168.1.255 Entering Failsafe!
telnetd -l /bin/login.sh /dev/null 21
}
lock /tmp/.failsafe
+ [ -x /sbin/3rdparty_failsafe ] /sbin/3rdparty_failsafe
ash --login
}
@@ -62,9 +62,10 @@
exec $M0 $M1 20
echo - preinit -
-echo Press CTRL-C for failsafe
-trap 'FAILSAFE=true' INT
-trap 'FAILSAFE=true' USR1
+trap 'echo 1 /tmp/.failsafe-true; lock -u /tmp/.wait-failsafe ; rm -f /tmp/.wait-failsafe' INT
+trap 'echo 1 /tmp/.failsafe-true; lock -u /tmp/.wait-failsafe ; rm -f /tmp/.wait-failsafe' USR1
+
[ -e /etc/preinit.arch ] . /etc/preinit.arch
set_state preinit
echo $HOTPLUG /proc/sys/kernel/hotplug
+
@@ -68,7 +68,56 @@
+TIMEOUT=$(cat /etc/preinit.timeout)
+
+[ -n $TIMEOUT ] || TIMEOUT=1
+TIMEOUT=${TIMEOUT%%\ *}
+[ $TIMEOUT -ge 1 ] || TIMEOUT=1
+
+TIMER=$TIMEOUT
+lock /tmp/.wait-failsafe
+{
+while [ $TIMER -gt 0 ]; do
+echo $TIMER /tmp/.failsafe-wait-sec
+ TIMER=$(($TIMER - 1))
+ sleep 1
+done
+lock -u /tmp/.wait-failsafe
+rm -f /tmp/.wait-failsafe
+}
+
+if [ $M0 = /dev/console ]; then
+echo Press fENTER for failsafe
+# if we're on the console we wait for input
+{
+ while [ -r /tmp/.wait-failsafe ]; do
+ TIMER=$(cat /tmp/.failsafe-wait-sec)
+
+ [ -n $TIMER ] || TIMER=1
+ TIMER=${TIMER%%\ *}
+ [ $TIMER -ge 1 ] || TIMER=1
+ {
+ read -t $TIMER DOFAILSAFE
+ if [ $DOFAILSAFE = f ]; then
+ echo 1 /tmp/.failsafe-true
+ lock -u /tmp/.wait-failsafe
+ rm -f /tmp/.wait-failsafe
+ fi
+ }
+ done
+}
+else
+echo Waiting for external event (e.g. reset button) for failsafe
+# if we're not on the console we sleep in case reset is pressed
+fi
+lock -w /tmp/.wait-failsafe
+
+[ $(cat /tmp/.failsafe-true) = 1 ] FAILSAFE=true
export FAILSAFE
+
eval ${FAILSAFE:+failsafe}
lock -w /tmp/.failsafe
+echo - regular boot -
+echo - mount -
+
Index: package/base-files/Makefile
===
--- package/base-files/Makefile (revision 17031)
+++ package/base-files/Makefile (working copy)
@@ -56,6 +56,7 @@
/etc/profile
/etc/shells
/etc/sysctl.conf
+/etc/config/rootfsflash
$(call $(TARGET)/conffiles)
endef
@@ -140,6 +140,10 @@
$(call Build/Compile/Default)
endef
+define ImageConfigOptions
+ echo $(if $(CONFIG_TARGET_PREINIT_TIMEOUT),$(CONFIG_TARGET_PREINIT_TIMEOUT),5) $(1)/etc/preinit.timeout
+endef
+
define Package/base-files$(TARGET)/install
$(CP) ./files/* $(1)/
if [ -d $(GENERIC_PLATFORM_DIR)/base-files/. ]; then \
@@ -192,7 +210,8 @@
rm -f $(1)/var
ln -sf /tmp $(1)/var
mkdir -p $(1)/etc
- ln -sf /tmp/resolv.conf /tmp/fstab /tmp/TZ $(1)/etc/
+ ln -sf /tmp/resolv.conf /tmp/fstab /tmp/TZ $(1)/etc/
+ $(call ImageConfigOptions,$(1))
$(call Package/base-files/install-target,$(1))
for conffile in $(1)/etc/config/*; do \
if [ -f conffile ]; then \
Index: Config.in
[OpenWrt-Devel] [PATCH] Fix sysupgrade save configuration
Ticket #5652 now contains a patch, attached here, to fix the following:
sysupgrade save the configuration in sysupgrade.tgz but that file never
gets restored on reboot after flashing a new firmware image, so
configuration changes are always lost across firmware upgrades.
The attached patch fixes the offending failing component which is mtd
-j. It was a simple C coding error in with sizeof(#define) was taken
when sizeof returns the size of a type not an object. Since the #define
was a byte string the size was 1 instead of 4 (the length of the JFFS2
DEADC0DE marker). I replace sizeof with another define for the length
of the marker.
--
And that's my crabbing done for the day. Got it out of the way early,
now I have the rest of the afternoon to sniff fragrant tea-roses or
strangle cute bunnies or something. -- Michael Devore
GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org
The C Shore (Daniel Dickinson's Website) http://www.bmts.com/~cshore
Index: package/mtd/src/mtd.c
===
--- package/mtd/src/mtd.c (revision 17187)
+++ package/mtd/src/mtd.c (working copy)
@@ -285,7 +285,7 @@
break;
if (jffs2file) {
- if (memcmp(buf, JFFS2_EOF, sizeof(JFFS2_EOF)) == 0) {
+ if (memcmp(buf, JFFS2_EOF, JFFS2_EOF_LEN) == 0) {
if (!quiet)
fprintf(stderr, \b\b\b );
if (quiet 2)
Index: package/mtd/src/mtd.h
===
--- package/mtd/src/mtd.h (revision 17187)
+++ package/mtd/src/mtd.h (working copy)
@@ -8,6 +8,7 @@
#endif
#define JFFS2_EOF \xde\xad\xc0\xde
+#define JFFS2_EOF_LEN 4
extern int quiet;
extern int mtdsize;
Index: package/mtd/src/jffs2.c
===
--- package/mtd/src/jffs2.c (revision 17187)
+++ package/mtd/src/jffs2.c (working copy)
@@ -222,7 +222,7 @@
pad(erasesize);
/* add eof marker, pad to eraseblock size and write the data */
- add_data(JFFS2_EOF, sizeof(JFFS2_EOF) - 1);
+ add_data(JFFS2_EOF, JFFS2_EOF_LEN - 1);
pad(erasesize);
free(buf);
@@ -324,7 +324,7 @@
pad(erasesize);
/* add eof marker, pad to eraseblock size and write the data */
- add_data(JFFS2_EOF, sizeof(JFFS2_EOF) - 1);
+ add_data(JFFS2_EOF, JFFS2_EOF_LEN - 1);
pad(erasesize);
err = 0;
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PROPOSAL] Solving changing CRC in firmware image prevents boot
The problem: On brcm63xx some routers check the CRC of the firmware on every boot. The JFFS2 EOF marker (DEADC0DE) is part of the image that is flashed. That means the CRC changes when DEADC0DE is moved, and then whenever those same bytes where it was are modified (e.g. on an inode change), it changes again. That means that after firstboot and creation of the jffs2 filesystem, the routers refuse to boot. Solution: I would like to solve this by making the EOF marker not be part of the firmware image. The current solution for other platforms is to modify the kernel. I'm not comfortable with that solution because it involves modifying and reflashing the erase block with the imagetag (CRC and record of the offsets and length of the kernel and rootfs). I think that's kind of dangerous and an ugly hack. To do it the way I am suggesting, we would: 1) instead of putting the DEADC0DE in the firmware image, add it in mount_root. I've got some test code with this, but it has to be redone because the patch was combined with other changes 2) for sysupgrade we add a new parameter that is like -j but instead of looking for DEADC0DE it looks for another magic that we use to indicate the end of the rootfs (this also could be used to ensure that rootfs_data parition starts after the rootfs, not after the squashfs, which isn't necessarily the same thing, but is what current happens) 3) To get an equivalent functionality to the current situation where flashing the firmware erases and rewrites the jffs2 (in the case of a squashfs or jffs2 filesystem), we would introduce an NVRAM variable that is created on firstboot. If the variable disappears (the reset button is held down for long enough to reset the nvram), we do firstboot again, which would recreate the flash filesystem. Basically a deadman switch. I'd like comments on this approach or reasons why the kernel hack isn't as bad as it seems. I'd prefer my approach because I think it's easier to change and understand, and it paves the way for an easy way to achieve a usb rootfs. (I've written code but not tested it yet for the usb rootfs, and I see things I'd like to change, so I consider the code not ready to release, but I know it can be done). Regards, Daniel -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://www.bmts.com/~cshore 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] Fix sysupgrade save configuration
On Tue, 11 Aug 2009 03:18:58 +0200 Felix Fietkau n...@openwrt.org wrote: Daniel Dickinson wrote: Ticket #5652 now contains a patch, attached here, to fix the following: sysupgrade save the configuration in sysupgrade.tgz but that file never gets restored on reboot after flashing a new firmware image, so configuration changes are always lost across firmware upgrades. The attached patch fixes the offending failing component which is mtd -j. It was a simple C coding error in with sizeof(#define) was taken when sizeof returns the size of a type not an object. Since the #define was a byte string the size was 1 instead of 4 (the length of the JFFS2 DEADC0DE marker). I replace sizeof with another define for the length of the marker. The patch looks wrong to me. sizeof on a constant string should return its length + 1 (for the null byte). In your patch however you use a length value of 3, which doesn't make any sense. Are you really sure that in your case it substitutes the sizeof expression with a value of 1 or is this a guess? That was my understanding. Perhaps the error was in fact that the code was taking sizeof - 1, which is 3 instead of 4. I fixed it on the patch which is on ticket #5652, but you're right the patch posted here was wrong. -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://www.bmts.com/~cshore 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] [RFC] preinit/failsafe customization/modularization
On Tue, 11 Aug 2009 10:25:00 -0700 (PDT) Jac Goudsmit jac_gouds...@yahoo.com wrote: On the other hand, I would say the preinit should be very small and self-contained, to minimize the chance of bugs or security problems. After all a simple mistake can brick a device at preinit time. As far as I understand, preinit should provide fail-safe/fallback mechanisms, and I wonder if your system (which iterates files in /etc/preinit.d/conf.d and other locations) might invite problems. I can easily imagine users bricking their devices by adding, deleting or changing files in unexpected ways, and I see opportunities for evildoers to plug in malicious software, and that would be bad at preinit time because when something is wrong with your system, you'll want a preinit to behave in a perfectly predictable way to bring the system back to working order. If you use a squashfs the preinit is pluggable only at firmware build time. Anything not on the squashfs doesn't affect preinit, because preinit runs before the rootfs is mounted. The object is not to make the system configurable, but to make it configurable by the firmware builder (e.g. a vendor, VAR, or service provider who wants to use OpenWRT, as is the case of the project I'm working on). For a jffs2 filesystem (e.g. not squashfs) the preinit is modifiable anyway, so I don't see it as any more dangerous. It would be better to store all the settings in one file, perhaps hard-code them at the top of the script at build time, and maybe (for targets that support this) allow a removable device like a USB stick to hold override settings. That way, even though the configuration can be changed at runtime (by plugging in a USB stick or whatever), it's always possible to revert to the flash settings by unplugging it. Not to worry, the preinit always uses the flash settings. I also wonder how much extra space a modularized preinit might use up on small devices. Maybe there should be a master switch in the configuration between Ye Olde non-modular preinit, or the New Shiny preinit stuff? It shouldn't make a noticable difference because it's a squashfs. So... my vote is Yes on the configurable preinit, but a firm Hmmm maybe not on modularizing it. Feel free to flame back if this doesn't make sense -- I'm still a beginner with OpenWRT and as I said I only glanced at your code so I may be totally off on some (or all?) of my arguments. Heh. I appreciate the feedback. I will also be posting an example of a package that takes advantage of the modular system to extend failsafe to autorestore settings and firmware from a server when failsafe mode is entered (while keeping the option to truly drop to failsafe if need be). So, do you feel better about it knowing that it is only the firmware builder who modifies the behaviour of preinit/failsafe? Regards, Daniel -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://www.bmts.com/~cshore 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] Fix sysupgrade save configuration
On Tue, 11 Aug 2009 03:18:58 +0200
Felix Fietkau n...@openwrt.org wrote:
Are you really sure that in your case it substitutes the sizeof
expression with a value of 1 or is this a guess?
With your reminder of sizeof on constant arrays, I was able to find the
true offender and now the patch affects exactly one line of mtd.c.
With this patch sysupgrade is able to save the configuration during
firmware flash for restoring after rebooting.
--
And that's my crabbing done for the day. Got it out of the way early,
now I have the rest of the afternoon to sniff fragrant tea-roses or
strangle cute bunnies or something. -- Michael Devore
GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org
The C Shore (Daniel Dickinson's Website) http://www.bmts.com/~cshore
Index: package/mtd/src/mtd.c
===
--- package/mtd/src/mtd.c (revision 17236)
+++ package/mtd/src/mtd.c (working copy)
@@ -285,7 +285,7 @@
break;
if (jffs2file) {
- if (memcmp(buf, JFFS2_EOF, sizeof(JFFS2_EOF)) == 0) {
+ if (memcmp(buf, JFFS2_EOF, sizeof(JFFS2_EOF) - 1) == 0) {
if (!quiet)
fprintf(stderr, \b\b\b );
if (quiet 2)
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] replace /jffs with usb stick
On Mon, 17 Aug 2009 20:05:19 +0200 bud.d...@suisse.org wrote: Hi all, I am having a hard time to find the place where mounting root / really happens .. http://oldwiki.openwrt.org/OpenWrtDocs%282f%29OpenWrtDocs%282f%29lKamikazeBootHowTo.html is not helpful https://forum.openwrt.org/viewtopic.php?id=10816 seems to be out of date. I added comments to /sbin/mount_root (but it doesn't seem to be executed at all) e.g. 'echo comment /tmp/test' or echo comment or logger comment I only get feedback from /etc/init.d/boot .. but everything seems to be mounted there already. I want to replace the jffs partition with the ext3 on an usb stick during boot on brcm-2.4. Any help appreciated :) On first boot it is mounted in /bin/firstboot. On subsequent boots it is mounted in /sbin/mount_root -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://www.bmts.com/~cshore signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [UPDATE] Failsafe provider restore
=$(if $(CONFIG_TARGET_PREINIT_IP),$(CONFIG_TARGET_PREINIT_IP),192.168.1.1)' $(1)/etc/preinit.d/conf.d/10_preinit_netmsg
+ echo 'pi_netmask=$(if $(CONFIG_TARGET_PREINIT_NETMASK),$(CONFIG_TARGET_PREINIT_NETMASK),255.255.255.0)' $(1)/etc/preinit.d/conf.d/10_preinit_netmsg
+ echo 'pi_broadcast=$(if $(CONFIG_TARGET_PREINIT_BROADCAST),$(CONFIG_TARGET_PREINIT_BROADCAST),)' $(1)/etc/preinit.d/conf.d/10_preinit_netmsg
+endef
+
+
define Package/base-files/install
$(CP) ./files/* $(1)/
if [ -d $(GENERIC_PLATFORM_DIR)/base-files/. ]; then \
@@ -191,6 +210,7 @@
ln -sf /tmp $(1)/var
mkdir -p $(1)/etc
ln -sf /tmp/resolv.conf /tmp/fstab /tmp/TZ $(1)/etc/
+ $(call ImageConfigOptions,$(1))
$(call Package/base-files/install-target,$(1))
for conffile in $(1)/etc/config/*; do \
if [ -f conffile ]; then \
Index: package/base-files/files/lib/upgrade/common.sh
===
--- package/base-files/files/lib/upgrade/common.sh (revision 17550)
+++ package/base-files/files/lib/upgrade/common.sh (working copy)
@@ -45,7 +45,7 @@
}
run_ramfs() { # command [...]
- install_bin /bin/busybox /bin/ash /bin/sh /bin/mount /bin/umount /sbin/pivot_root /usr/bin/wget /sbin/reboot /bin/sync /bin/dd /bin/grep /bin/cp /bin/mv /bin/tar /usr/bin/md5sum /usr/bin/[ /bin/vi /bin/ls /bin/cat /usr/bin/awk /usr/bin/hexdump /bin/sleep /bin/zcat /usr/bin/bzcat
+ install_bin /bin/busybox /bin/ash /bin/sh /bin/mount /bin/umount /sbin/pivot_root /usr/bin/wget /sbin/reboot /bin/sync /bin/dd /bin/grep /bin/cp /bin/mv /bin/tar /usr/bin/md5sum /usr/bin/[ /bin/vi /bin/ls /bin/cat /usr/bin/awk /usr/bin/hexdump /bin/sleep /bin/zcat /usr/bin/bzcat /bin/lock /bin/netmsg
install_bin /sbin/mtd
for file in $RAMFS_COPY_BIN; do
install_bin $file
Index: utils/failsafe-provider-restore/files/etc/preinit.d/run.d/failsafe_10_provider_echo_command
===
--- utils/failsafe-provider-restore/files/etc/preinit.d/run.d/failsafe_10_provider_echo_command (revision 0)
+++ utils/failsafe-provider-restore/files/etc/preinit.d/run.d/failsafe_10_provider_echo_command (revision 0)
@@ -0,0 +1,14 @@
+#!/bin/sh
+
+# command to use for echoing log messages
+# Copyright 2009 Daniel Dickinson, Licensed under the GPL Version 2 or later
+
+pr_failsafe_echo () {
+ echo $1
+ netmsg $fs_failsafe_broadcast $1
+}
+
+failsafe_10_provider_echo_command () {
+#dummy command
+:
+}
Index: utils/failsafe-provider-restore/files/etc/preinit.d/run.d/failsafe_50_get_dhcp_address
===
--- utils/failsafe-provider-restore/files/etc/preinit.d/run.d/failsafe_50_get_dhcp_address (revision 0)
+++ utils/failsafe-provider-restore/files/etc/preinit.d/run.d/failsafe_50_get_dhcp_address (revision 0)
@@ -0,0 +1,33 @@
+#!/bin/sh
+
+# Get IP address for WAN via DHCP
+# Copyright 2009 Daniel Dickinson, Licensed under the GPL Version 2 or later
+
+pr_failsafe_dhcpc () {
+if [ -n $fsprovider_ifname ] grep $fsprovider_ifname /proc/net/dev /dev/null; then
+ pr_failsafe_echo Getting WAN ip via DHCP
+ /sbin/udhcpc -t10 -i $fsprovider_ifname -n
+ retval=$?
+else
+ pr_failsafe_echo ERROR: WAN inteface '$fsprovider_ifname' can't be configured
+ do_reboot
+fi
+return $retval
+}
+
+failsafe_50_get_dhcp_address () {
+if [ $MANUALFAILSAFE = true ]; then
+ return 0
+fi
+while [ $retval != 0 ]; do
+ failsafe_echo Getting WAN IP address via DHCP
+ pr_failsafe_dhcpc
+ retval=$?
+ sleep $fsprovider_link_status_sleep
+ reboot_link_status_changed
+done
+
+ln -s /tmp/resolv.conf.auto /tmp/resolv.conf
+
+poll_link_status
+}
Index: utils/failsafe-provider-restore/files/etc/preinit.d/run.d/failsafe_10_reboot_command
===
--- utils/failsafe-provider-restore/files/etc/preinit.d/run.d/failsafe_10_reboot_command (revision 0)
+++ utils/failsafe-provider-restore/files/etc/preinit.d/run.d/failsafe_10_reboot_command (revision 0)
@@ -0,0 +1,50 @@
+#!/bin/sh
+
+do_reboot () {
+pr_failsafe_echo Checking reboot status
+# Here we make sure that we're not flashing or some other operation
+# where rebooting is liable to result in bricking of the router
+lock /tmp/.reboot_semaphore
+local reboot_status=$(cat /tmp/.reboot_status 2/dev/null)
+if [ $reboot_status = 0 ]; then
+ pr_failsafe_echo Not rebooting; sensitive operation in progress
+ return 0
+fi
+local reboot_status=$(cat /tmp/root/tmp/.reboot_status 2/dev/null)
+if [ $reboot_status = 0 ]; then
+ pr_failsafe_echo Not rebooting; sensitive operation in progress
+ return 0
+fi
+echo 1 /tmp/.reboot_status
+( echo 1 /tmp/root/tmp/.reboot_status ) 2/dev/null
+lock -u /tmp/.reboot_semaphore
+pre_failsafe_echo Failsafe autorestore rebooting system
+reboot
+sleep 10
+echo b 2/dev/null /proc/sysrq-trigger
+# This is just in case reboot
[OpenWrt-Devel] [INFO] Failsafe provider restore and why care?
Hi all, I'm working on a project that is based on OpenWRT for what will be a 'live' commercial application. We are giving back are changes (due to a great boss), and my boss is really excited by the failsafe provider restore and I'd like to tell you why in hopes that it will help with the adoption of my preinit and failsafe changes (on which the provider restore depends). We feel that working with and giving back to the OpenWRT community is not only good for us, but good for OpenWRT as well. We hope you agree. The failsafe provider restore is part of what my boss calls a 'next generation provisioning system'. Provisioning is important for service providers because they need to get they configurations and updates to firmware and configuration to many, many routers and in order scale, need to be able to do so without having to call eash customer, or even to manually do a firmware and configuration update for every router. I'll crib from the presentation my boss made for demos * Next generation auto-provisioning system for [routers; we talk about our application here] * Very lightweight, small footprint web 2.0 technologies * Easy customized for different Service Providers and deployment models * Designed to by deployed by the end customer, without a truck roll, and without a tech supoprt call to the Service Provider Agent: * When failsafe invoiced establishes HTTP (future HTTPS) session with server * If recognized, and authorized, it downloads * Custom configuration files for specific customer (or for a particular user group if not a per-router ID) * Service Provider-specific firmware * MD5 has to verify file integrity * Loads new firmware and settings and reboots * Process can be used for first boot, system upgrade, and brick recovery Currently for brcm63xx this requires serial console because we don't have an available reset button. Once the reset button works, failsafe mode will be able to be entered via reset during failsafe wait period (indicated by the soon to be availabed LEDs for preinit mode) Basically if this is in the firmware you can update all your routers by pressing the reset button, or for certain types of bricking, recover via reset button. It is also possible to do upgrades of many units in the field, and with future work we'll be doing, to schedule updates for routers that stay in contact with us via a reverse connect tunnel. -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] bug in conditional dependencies
define Package/usb-root SECTION:=utils CATEGORY:=Utilities TITLE:=USB as root filesystem DEPENDS:=+kmod-usb-core +CONFIG_USBROOT_FS_EXT2:kmod-fs-ext2 +kmod-usb-storage +CONFIG_USBROOT_FS_EXT3:kmod-fs-ext3 +CONFIG_USBROOT_FS_REISERFS:kmod-fs-reiserfs +CONFIG_USBROOT_HOST_OHCI:kmod-usb-ohci +CONFIG_USBROOT_HOST_UHCI:kmod-usb-uhci +CONFIG_USBROOT_FS_EXT2:e2fsprogs +CONFIG_USBROOT_FS_EXT3:e2fsprogs endef Isn't resulting in e2fsprogs being selected even though CONFIG_USBROOT_FS_EXT2 is set via choice prompt Root filesystem typeif USBROOTOPT default USBROOT_FS_EXT2 help Select the type of filesystem to use for the root filesystem on the usb root. config USBROOT_FS_EXT2 bool ext2 config USBROOT_FS_EXT3 bool ext3 config USBROOT_FS_REISERFS bool reiserfs and in menuconfig selecting ext2 for the Root filesystem type option Or am I missing something? Regards, Daniel -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com 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] Update [RFC] preinit/failsafe fix/enhance
On Sun, 6 Sep 2009 21:40:19 -0400
Daniel Dickinson crazycsh...@gmail.com wrote:
On Sun, 06 Sep 2009 01:13:47 +0200
Felix Fietkau n...@openwrt.org wrote:
Daniel Dickinson wrote:
Hi all,
I've refreshed the patches to work with current trunk (as the old
patches were no longer applying cleanly due to recent changes).
There are also a couple of minor functional changes some of which
make the usb root stuff I'm working on easier.
I'd really appreciate if there could be some review/comments on
these patches soon. It's been a significant period of time and I
haven't heard from full devs on what they think, although a couple
of list members like the idea of the modularization I have done.
In principle, it looks useful. One thing I don't like that well is
that every hook you add has to be a separate file
in /etc/preinit.d/run.d I think it would be cleaner to have just
an /etc/preinit.d with files that are sourced at the beginning of
preinit, which can then add functions to various hooks that are
defined by preinit. For instance the netmsg plugin would then do
something like this:
netmsg_send_message() {
netmsg [...]
}
netmsg_send_init() {
failsafe_ip
netmsg_send_message Press reset to enter failsafe now
}
netmsg_send_enter() {
netmsg_send_message Entering Failsafe!
}
add_hook init netmsg_send_init
add_hook failsafe_enter netmsg_send_enter
Hmmm...I'm not as fond of that solution because it is limited to
specific hooks. My solution is much more generic. It sources the
files in /etc/preinit.d/run.d/stage_* (at each stage) and then
executes the functions of the same name as the file. That means
packages can drop in new functionality without having to modify
preinit for additional hooks. I've used that for the failsafe
provider I have posted, and am using it for the usb root I am
created. Those options exist as packages. Without packages things
act as usual, with the packages there is a change in functionality
that wouldn't be possible with predefined hooks, unless you're
constantly updating the available hooks.
Well, since you're the only one who's replied, and I've reread your
reply and thought maybe I misunderstood you, perhaps I should make sure
I understand what you mean. My concern is that I want to be able to
drop in a package to modify the behaviour of preinit or failsafe, and
then, when needed (I've used it already) to drop in another package
that modifies that package that modifies preinit / failsafe.
How would that look with your suggested solution?
How does you solution go about adding arbitrary new functions that are
called at the appropriate time in the boot sequence (I didn't follow
that from your example, so maybe I'm not understanding what you mean).
In the solution I presented the boot looks something like:
1) Stuff that happens always because it's in /etc/preinit
2) iterate through the files in /etc/preinit.d/conf.d (in lexical sort
order) and eval the files (.e.g 01preinit.conf's variables of the form
veriable=value are entered into the environment, then 02preinit.conf's
variable=value, so that 02preinit.conf overrides 01preinit.conf, if
they variable names are the same (otherwise it's additive))
3) iterates through the files in /etc/preinit.d/run.d, sourcing the
files in lexical sort order. It also builds up a list of filenames
1) This means that functions in 02preinit.run override functions
in 01preinit.run, if different.
2) There can be an arbitrary number of functions per source
file, the only hard requirement is that each source file have a
function of the same name as the filename (see below)
3) If there are commands in the file that are not in a function
they are executed in the order of the files being sourced.
4) iterates through the the list of filenames and attempts to execute
functions with that name. That means that after the files have been
sourced, and possibily overridden, that the 'hook functions (which
are filenames)' are executed in lexical sort order.
This gives the ability to add new functions anywhere in the sort order,
as well as to override any function with a different version (including
null-op functions) before they are executed.
Is this possible with your solution and, if so, could you provide an
example of how it would work?
Or, if there is a way you could see to improve the way in which I
achieve my desired goals, could you suggest it?
Thanks!
Daniel
--
And that's my crabbing done for the day. Got it out of the way early,
now I have the rest of the afternoon to sniff fragrant tea-roses or
strangle cute bunnies or something. -- Michael Devore
GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org
The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com
signature.asc
Description: PGP signature
___
openwrt
[OpenWrt-Devel] *PING* [PATCH] Ctrl-C doesn't work on brcm63xx, ticket #5516
*PING*, Ticket #5516 Here's an updated patch in case the old ones won't apply, and I think is not a bad patch. Could it please be applied? I can't access failsafe mode on my brcm63xx-based routers without it because Ctrl-C doesn't work. This patch doesn't eliminate Ctrl-C, it just adds regular keypress (in this patch fENTER) to enter failsafe. Also I should note that others on other platforms have reported problems with Ctrl-C, possibly due to bugs in ash, or for other reasons. It would be nice if we could enter failsafe even when the pesky Ctrl-C doesn't work. It's been *four* months since I first proposed a patch. Could someone please look at this? -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] /etc and non-config files (like functions.sh)
Hi all, I was discussing the changes to preinit, mount_root, and and firstboot that I am working on, with Jo (xMff), specifically to ask where he thought I should put code that was common to the reworked mount_root and firstboot. In that discussion we came to the conclusion that non-config files (i.e.g code that's integral to the system) really shouldn't be in /etc because backing up /etc, flashing and then restore /etc could potentially overwrite files that are required code in the system. Therefore I'm planning on putting my shared code under /lib/boot (and preinit functions (where order matters) under /lib/boot/preinit, and firstboot (likewise) under /lib/boot/firstboot). However there is a change that Jo and I thought would be a good idea, but which definitely requires discussion, and that is putting /etc/functions.sh under /lib/functions/functions.sh (or somesuch), with a symlink from /etc/function.sh. Also /lib/functions could be used for shared functions that are not used often enough to really belong in functions.sh, but make sense to be shared. In the same vein, though I didn't think of this until Jo when home, is to move /etc/preinit to /lib/boot/preinit.sh or somesuch. That would be a major change though since it's called as init by all the platforms. And not as necessary for squashfs or other readonly filesystems, when doing backup/restore of /etc. What do the rest of you think, of making the /lib move for a) functions.sh and b) preinit? Regards, Daniel -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] /etc and non-config files (like functions.sh)
On Wed, 2010-01-13 at 15:06 -0500, Stefan Monnier wrote: What do the rest of you think, of making the /lib move for a) functions.sh and b) preinit? Sounds like a good idea to me. Might as well move /etc/init.d and rc.common while we're at it - but not without compatibility symlinks, both for users and for applications that rely on the old layout. Not sure I agree for /etc/init.d. I see why you'd want that, but there's a long tradition behind it and most GNU/Linux distributions still use /etc/init.d as well. And it's fairly normal for a user to add scripts in there as part of the local customizations. If you store the scripts under /lib/init.d, but keep symlinks in /etc/init.d, and keep the scripts running from /etc/init.d, as is current, that should take care of it (presumably tar or whatever will save the symlink not the contents of the file at the end of the symlink, so when the init.d files change the changes are present for the system boot). Or am I missing something? -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] NB: previous preinit patch is missing files
Hi, I'm doing a fresh build with modifications to my previous preinit patches. It seems the patch posted to the list is missing files. That's when I get for not building from the patch before posting. Sorry about that. Regards, Daniel -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] new GNU libc charset conversion modules package gconv-modules
On Fri, 2010-01-15 at 19:08 +0200, Zintis wrote: Just a reminder of this patch. I haven't seen it committed yet. OpenWRT has glibc support but for samba3 (and probably other packages) to work it needs gconv support. This patch adds gconv-modules package I've committed this. Is there a Trac# for this? I didn't close it if there is. I thought of this after committing, but should it perhaps not be in base? How many other packages depend on it? I'll fix it to be in libs if it's not a hard requirement for most packages. -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] new GNU libc charset conversion modules package gconv-modules
I've committed this. Is there a Trac# for this? I didn't close it if there is. I thought of this after committing, but should it perhaps not be in base? How many other packages depend on it? I'll fix it to be in libs if it's not a hard requirement for most packages. FYI, I've changed this already. I should have done it that way to begin with. I reread the original message and the only package known for certain to use this is samba. It perhaps should have a conditional depends on it. -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] set correct gconv-modules version
On Sat, 2010-01-23 at 20:55 +0200, Zintis wrote: gconv-modules depends on glibc. Set gconv-modules version from glibc version. Signed-off-by: Zintis Petersons zintis.peters...@e-mail.lv Applied r19323. Next time please make the patch from the packages root. Regards, Daniel -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] More preinit fixes
Ticket #6575: Patch for brcm47xx, hopefully it will boot again. Working
with folds on IRC to see if we can make this happen.
Also attached here.
--
And that's my crabbing done for the day. Got it out of the way early,
now I have the rest of the afternoon to sniff fragrant tea-roses or
strangle cute bunnies or something. -- Michael Devore
GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org
The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com
Index: target/linux/brcm-2.4/base-files/lib/preinit/15_set_preinit_interface_brcm
===
--- target/linux/brcm-2.4/base-files/lib/preinit/15_set_preinit_interface_brcm (revision 19339)
+++ target/linux/brcm-2.4/base-files/lib/preinit/15_set_preinit_interface_brcm (working copy)
@@ -4,7 +4,7 @@
[ -n $pi_ifname ] grep $pi_ifname /proc/net/dev /dev/null {
if [ $pi_preinit_net_messages = y ] || [ $pi_failsafe_net_message = true ] [ $pi_preinit_no_failsafe_netmsg != y ]; then
netmsg $pi_broadcast $1
- }
+ fi
}
}
signature.asc
Description: This is a digitally signed message part
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Preinit fixes
On Tue, 2010-01-26 at 14:19 +0100, Luigi 'Comio' Mantellini wrote: Hi All, Hi Daniel, thanks for this improvement. I have just a request from the documentation point of view: can anyone formalize a document with the init sequence, the hooks that can be used and any other useful information to customize the init process. I know that the source code is better a document... but I formal document can be easily reviewed in order to have a standard. Have you seen http://wiki.openwrt.org/doc/techref/preinit_mount ? -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Preinit fixes
On Tue, 2010-01-26 at 21:09 -0500, Stefan Monnier wrote: See, http://cshore.is-a-geek.com/openwrt/preinit_mount.html It's fully documented along with an example. Thanks. It's much better, but it still leaves several questions open: The doc is now on the wiki. Feel free to improve it as you can. It's at http://wiki.openwrt.org/doc/techref/preinit_mount Except for the modularization the preinit does the same thing, with the same code, as the previous preinit. I didn't change anything, except to make it modular, because the goal was a drop in replacement that would add a feature (ability to do addons) without causing devs or users to have to do anything (to the extent possible...preinit replacement obviously will have to be rewritten, but that would happen when there were any preinit changes, and now that should happen less often). Point is, complaints about how preinit works would have applied without these changes. Of course I think now it's easier to change certain bits. If you have specific thing you'd like to see changed file a ticket (or post to this list), preferably with patches. As for improving the docs...While docs can always be better, I prefer development, and I think I've already greatly improved the state of documentation compared to what it was, as far as preinit goes. It's on the wiki, so if you feel you understand the code well enough to improve it or the documention, please feel free to do so. I'm pretty satisfied with the work I've done, and while there may be some things that need changing, or bugs fixed, I'm moving on to other things (as Jo put it, a router should route, not boot, if you know what I mean). As always if you care about something I haven't worked on, well constructed patches and documentation changes are always welcome. -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Preinit fixes
satisfied with the work I've done, and while there may be some things that need changing, or bugs fixed, I'm moving on to other things (as Jo To clarify I mean that except for the things that need changing, or bugs fixed, I'm moving on to other thing. Regards, Daniel -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH]: Preinit for some target mixed up enabled_led with enabled_reset_button
This fixes that
--
And that's my crabbing done for the day. Got it out of the way early,
now I have the rest of the afternoon to sniff fragrant tea-roses or
strangle cute bunnies or something. -- Michael Devore
GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org
The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com
Index: target/linux/adm5120/base-files/lib/preinit/05_enable_reset_button_adm5120
===
--- target/linux/adm5120/base-files/lib/preinit/05_enable_reset_button_adm5120 (revision 19361)
+++ target/linux/adm5120/base-files/lib/preinit/05_enable_reset_button_adm5120 (working copy)
@@ -1,12 +1,12 @@
#!/bin/sh
-enable_leds() {
+enable_reset_button() {
insmod input-core
insmod input-polldev
insmod gpio_buttons
insmod button-hotplug
}
-boot_hook_add preinit_main enable_leds
+boot_hook_add preinit_main enable_reset_button
Index: target/linux/adm5120/base-files/lib/preinit/05_enable_leds_adm5120
===
--- target/linux/adm5120/base-files/lib/preinit/05_enable_leds_adm5120 (revision 19361)
+++ target/linux/adm5120/base-files/lib/preinit/05_enable_leds_adm5120 (working copy)
@@ -1,12 +0,0 @@
-#!/bin/sh
-
-enable_leds() {
- insmod input-core
- insmod input-polldev
- insmod gpio_buttons
- insmod button-hotplug
-}
-
-boot_hook_add preinit_main enable_leds
-
-
Index: target/linux/ar71xx/base-files/lib/preinit/05_enable_reset_button_ar71xx
===
--- target/linux/ar71xx/base-files/lib/preinit/05_enable_reset_button_ar71xx (revision 19361)
+++ target/linux/ar71xx/base-files/lib/preinit/05_enable_reset_button_ar71xx (working copy)
@@ -5,12 +5,12 @@
. /lib/ar71xx.sh
-preinit_enable_leds() {
+preinit_enable_reset_button() {
insmod input-core
insmod input-polldev
insmod gpio_buttons
insmod button-hotplug
}
-boot_hook_add preinit_main preinit_enable_leds
+boot_hook_add preinit_main preinit_enable_reset_button
Index: target/linux/ar71xx/base-files/lib/preinit/05_enable_leds_ar71xx
===
--- target/linux/ar71xx/base-files/lib/preinit/05_enable_leds_ar71xx (revision 19361)
+++ target/linux/ar71xx/base-files/lib/preinit/05_enable_leds_ar71xx (working copy)
@@ -1,16 +0,0 @@
-#
-# Copyright (C) 2009 OpenWrt.org
-#
-
-. /lib/ar71xx.sh
-
-
-preinit_enable_leds() {
- insmod input-core
- insmod input-polldev
- insmod gpio_buttons
- insmod button-hotplug
-}
-
-boot_hook_add preinit_main preinit_enable_leds
-
signature.asc
Description: This is a digitally signed message part
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Remove Ctrl-C prompt...impossible on /dev/console
Preinit still had a few references to Ctrl-C even we have figured out that Ctrl-C to interrupt is not available on /dev/console because it's not a controlling terminal and it would be a bad idea to make it one (because it would interfere with normal operating mode). -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com Index: target/linux/x86/base-files/lib/preinit/45_failsafe_x86 === --- target/linux/x86/base-files/lib/preinit/45_failsafe_x86 (revision 19361) +++ target/linux/x86/base-files/lib/preinit/45_failsafe_x86 (working copy) @@ -7,7 +7,7 @@ grep 'failsafe=' /proc/cmdline /dev/null FAILSAFE=true export FAILSAFE if [ $FAILSAFE != true ]; then preinit_net_echo Please press button now to enter failsafe -echo -n Press CTRL-C or +echo -n Press fs_wait_for_key f 'to enter failsafe mode' $fs_failsafe_wait_timeout FAILSAFE=true export FAILSAFE fi } Index: target/linux/x86/olpc/base-files/lib/preinit/45_failsafe_x86 === --- target/linux/x86/olpc/base-files/lib/preinit/45_failsafe_x86 (revision 19361) +++ target/linux/x86/olpc/base-files/lib/preinit/45_failsafe_x86 (working copy) @@ -7,7 +7,7 @@ grep 'failsafe=' /proc/cmdline /dev/null FAILSAFE=true export FAILSAFE if [ $FAILSAFE != true ]; then preinit_net_echo Please press button now to enter failsafe -echo -n Press CTRL-C or +echo -n Press fs_wait_for_key f 'to enter failsafe mode' $fs_failsafe_wait_timeout FAILSAFE=true export FAILSAFE fi } Index: target/linux/pxcab/base-files/lib/preinit/45_failsafe_pxcab === --- target/linux/pxcab/base-files/lib/preinit/45_failsafe_pxcab (revision 19361) +++ target/linux/pxcab/base-files/lib/preinit/45_failsafe_pxcab (working copy) @@ -7,7 +7,7 @@ grep 'failsafe=' /proc/cmdline /dev/null FAILSAFE=true export FAILSAFE if [ $FAILSAFE != true ]; then preinit_net_echo Please press button now to enter failsafe -echo -n Press CTRL-C or +echo -n Press fs_wait_for_key f 'to enter failsafe mode' $fs_failsafe_wait_timeout FAILSAFE=true export FAILSAFE fi } Index: package/base-files/files/lib/preinit/30_failsafe_wait === --- package/base-files/files/lib/preinit/30_failsafe_wait (revision 19361) +++ package/base-files/files/lib/preinit/30_failsafe_wait (working copy) @@ -78,7 +78,7 @@ pi_failsafe_net_message=true preinit_net_echo Please press button now to enter failsafe pi_failsafe_net_message=false -echo -n Press CTRL-C or +echo -n Press fs_wait_for_key f 'to enter failsafe mode' $fs_failsafe_wait_timeout FAILSAFE=true export FAILSAFE } signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Hotplug automount fixes/enhancements
On Sat, 2010-01-30 at 12:47 +0100, edgar.sol...@web.de wrote: (stability) Quite a chunk of code. Did you write it from scratch? Yes How thoroughly is this tested by now? Well I've tested a number of scenarios / code paths, but there is probably something I've missed. Does this work with kernel 2.4? Lot's of users are stuck to these kernels. No reason it shouldn't. (packaging) I don't mean to be picky, but wouldn't it make sense to keep code that depends on specific package with that package? This could result in /lib/functions/mount.sh ... mount.ext2.sh ... mount.xfs.sh ... mount.swap.sh ... fsck.sh ... fsck.ext2.sh ... fsck.xfs.sh ... and so on This would make the initial space used smaller and it grows with the needed functionality. It will get rid of all the if/elif redundant code and hence easier to maintain. I think the main place it's make a difference is the fsck, and I think that modularizing it does make sense. (usability) I like that you are putting infos to the logs. But there could be more. Especially when e.g. fsck'ing is enabled but the software missing. Or in every similar case, the user should see a statement to install the package or disable the request. Interesting idea. If I don't work on this, please feel free to do so. (fix) As I will surely add a file based swapping, swap should be disabled before unmounting the file systems. To be honest I'm not sure how useful the unmount in hotplug really is anyway...usually if it's called it mean the device has already been removed, I think. -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [IMPORTANT]: Preinit doesn't create /dev/null
This is because I foolishly used /dev/null before it was created, so an
empty file was created. This prevented the actual device node from
being created. The attached patch fixes that.
--
And that's my crabbing done for the day. Got it out of the way early,
now I have the rest of the afternoon to sniff fragrant tea-roses or
strangle cute bunnies or something. -- Michael Devore
GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org
The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com
Index: package/base-files/files/lib/preinit/20_device_fs_mount
===
--- package/base-files/files/lib/preinit/20_device_fs_mount (revision 19468)
+++ package/base-files/files/lib/preinit/20_device_fs_mount (working copy)
@@ -15,7 +15,7 @@
}
choose_device_fs() {
-if grep devfs /proc/filesystems /dev/null; then
+if grep devfs /proc/filesystems; then
do_mount_devfs
elif [ -x /sbin/hotplug2 ]; then
do_mount_hotplug
signature.asc
Description: This is a digitally signed message part
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Automount enhanced/fixed, also fstab
On Sun, 2010-02-07 at 16:26 +0100, edgar.sol...@web.de wrote: What do you think of packaging hotplug automount separately? Now that it's that sophisticated it takes several kilobytes of space. Space that is valuable to users without non-usb-routers. I think adding hotplugd-autmount (5K), plus a new package block-common (for the things used by fstab, hotplug and soon external rootfs) (8K), is not a good use of time and infrastracture. It could be done and I'll do it if the core devs want it, but honestly 13K is pretty miniscule and it greatly complicates life for the many with USB devices if it separate. -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Automount enhanced/fixed, also fstab
On Sun, 2010-02-07 at 22:32 +0100, edgar.sol...@web.de wrote: The swap parts should be part of base files. The needed swapon/off could come from util-linux or busybox. The idea was to have swap automount functionality only if swapon/of was actually present. I don't think that swapon/off from busybox is a supported configuration since it required manual hacking of the busybox config, but the core devs want me to make a separate package so that the automount swap can be used with busybox swapon/off then I will. Regards, Daniel -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Automount enhanced/fixed, also fstab
On Wed, 2010-02-17 at 11:56 +0100, edgar.sol...@web.de wrote: On 12.02.2010 22:13, Daniel Dickinson wrote: I think the packaging needs the following properties: 1) scripts for functionality (e.g. uuid and label, using blkid) are automatically installed if the main block-mount (as I've called) is installed, and the dependency is satisfied (.e.g if block-mount and blkid are both installed then block-blkid should automatically be selected for installation) I'd rather keep them optional, that's why the log tells if it misses blkid. Actually it doesn't. And it's only automatically selected if the base block-mount package is selected, so it is optional, but you don't have to worry about individual dependencies, and things work as expected without special effort out of the box. 2) It should be possible to pull in the dependencies for say block-blkid, from the base system menu (device-dependent submenu), rather than having to hunt down, say, blkid Sorry, not sure what you mean. Could you explain by example? Base System|Device Dependent should have packages such block-meta-blkid, that has the dependencies that pull in blkid and block-blkid (the package with the blkid mount stuff). 4) Scripts for functionality should only be installed if the necessary dependencies are present (e.g. block-blkid shouldn't be installed without blkid and block-mount) This will be ensured by dependency definition in the Makefile. NB: All conditions can't be met via a single package because menuconfig doesn't like circular dependencies me neither ;) .. but seriously. Circular dependencies only mean that somebody did not look deep enough into setting them properly. Not true, with the limited dependency language we have. Also note that the attached patches are incomplete...I'm having difficulty getting menuconfig to do what I want, so I'm showing you what I've got, and letting you try. will do so. because it it too small. I think that those wanting 2/8 devices to work should really think about working on a sister project that makes How did you perceive that openwrt is not targeting 2MB routers? a) developers have told me so b) ToH lists 2/8 devices as too small to be supported (and if there is any place it doesn't this is in error) 2/8 is very much tinkering with a system that just happens to be hackable to it, not a supported configuration. To reiterate a 2/8 device should really be done with a different choice-base than OpenWRT because in that case you want less functionality and smaller size. Currently you have to menuconfig/compile your own image for these devices. But I guess this is to keep the number of readymade images to build countable. No, it's because 2/8 is officially not supported. The fact that OpenWRT can be hacked to work on these devices should not be taken to mean that it's an officially supported configuration. It's your problem if you can't get it work, or it breaks because of changes on officially supported devices. usb-storage should simply be depending on it .. and then it will be there. It's not only applicable to usb though. Anyway I think making block-mount a part of profiles for devices with usb or other block devices (other than the boot rootfs), would be appropriate. Typically a package would be autoselected by different packages. e.g. packages that supply block devices: usb-storage, sdcard, ... autoselect packages that are needed to use these: e.g. block-mount block-mount is *required* to use usb, it's just nice to have. That's why profile selection not autoselect. -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] External Rootfs (e.g. USB)
On Mon, 2010-02-15 at 10:20 -0500, Stefan Monnier wrote: Here is the first part of the rootfs on external (i.e. not the squashfs, jffs, or boot root) rootfs (right not just usb, but can easily be extended to others). Thanks, this is a needed feature, indeed. This has to be manually configured after the first boot (and requires a reboot after a sysupgrade first boot). H... that's a problem. It means that you can't just have squashfs+extroot but need a jffs2 inbetween just for this little cconfig. Actually the squashfs/jffs2 is a fallback full firmware in the event of Inevitable Disaster(tm). config 'modules' 'modules' list 'fs_modules' 'fs-ext3' list 'controller' 'usb-core' list 'controller' 'usb-ohci' list 'controller' 'usb-storage' In my (limited experience), load all the available modules works just dandy: after all, these are only the modules available in the proto-root filesystem, so they're likely to be pretty close to the bare minimum. Could you explain the rationale for the relatively sophisticated config of modules you're proposing here? actually, the squashfs is likely to contain much more than the bare minimum; it's got whatever the user menuconfig selects as their base router configuration and it's harder to do something about things going wrong in preinit, so minimizing the modules loaded is useful. In addition hotplug doesn't coldplug in init. That means hotplug events aren't generated unless the modules are loaded after hotplug (in /etc/init.d/boot). And, finally, it's really not very sophisticated. It just loads modules if they're listed, the same was as load_modules for the main system does, except it loads specific modules instead of all available. It's not terribly complicated code in my opinion, so shouldn't be a problem. -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Automount enhanced/fixed, also fstab
On Thu, 2010-02-18 at 12:18 +0100, edgar.sol...@web.de wrote: I'd rather keep them optional, that's why the log tells if it misses blkid. Actually it doesn't. And it's only automatically selected if the base block-mount package is selected, so it is optional, but you don't have to worry about individual dependencies, and things work as expected without special effort out of the box. it does, for a good reason, functions/block.sh issues a log message if Heh, I had forgotten I had done that. blkid is missing, but uuid is used. I don't see how to separate a base block-mount package, because the majority is replacing old mounting routines. The thing to remember is the the /etc/init.d/fstab and 10-mount are for mounting optional filesystems. Neither of them is needed if you don't have storage beyond your rootfs (that is the boot rootfs (afaik squashfs, jffs2 or ext2), or squashfs (which is a boot rootfs) + jffs2 I'd expect the new functionality to split in something like base-mount (which would be of package base-files because it replaces the old fstab mounting and is therefore essential, consisting of the files But it's not essential. It's not used by preinit, which is where essential mounting is doing. /etc/fstab is kept around primarily in case some application expects to find something there and /etc/config/fstab is only used for optional filesystems. you put in buildroot/package/base-files except of the hotplugd stuff) menuconfig-Base system-hotplugd-block-automount (automount files, to enable automount feature) menuconfig-Base system-hotplugd-block-fsck (to enable fsck on hotplug events) I'd suggest to put all hotplugd functionality in buildroot/package/hotplugd-block. The hotplugd-block Makefile would contain the package definitions mentioned above. The reason I divided the packages the way I did is so the the scripts weren't installed unless package that provided the capability to provide the function was present. e.g. btrfs fsck script only included when btrfs-progs is. Initially the core of the block-mount was to be included in base-files (which is what what you're talking about switching to again, but I might as well have left things the way I had them if we're going to to do that, because there is 5-8k of scripts that are hotplug only, and that's it), and the other script functions were to be added along with the package that provided the program need to use it. You didn't like that because it was too big. The thing unless you subdivide to fairly small chunk you can't have a proper matching of scripts to available functionality. I am personally opposed to installed the scripts willy-nilly and spamming the syslog with error messages if the dependencies aren't met. I think that is bad design. It's much better to include the script only if it won't cause the user to get error messages. Now if the user uses a config file with unsupported functions that's a different story...that's a configuration error. 2) It should be possible to pull in the dependencies for say block-blkid, from the base system menu (device-dependent submenu), rather than having to hunt down, say, blkid Sorry, not sure what you mean. Could you explain by example? Base System|Device Dependent should have packages such block-meta-blkid, that has the dependencies that pull in blkid and block-blkid (the package with the blkid mount stuff). Why is this submenu 'Device Dependent' needed? What does it tell the user? Device Dependent is for things like block-* that depend on having 'external' (non-boot rootfs) devices , or on certain wifi devices (like the toggle you mentioned before). It's more general than hotplug-scripts because it includes things other than just hotplug scripts. I see two solutions to this: If we want to keep it simple and small it might make sense to simply activate busybox's blkid per default. Have to doublecheck the size increase though. More elaborate could be, a basefiles subpackage setting menuconfig-Base system-basefiles [ ] support mount by uuid or label . But maybe this is too much. I'd make it depending on the size increase above. me neither ;) .. but seriously. Circular dependencies only mean that somebody did not look deep enough into setting them properly. Not true, with the limited dependency language we have. Show me an example that is not solvable. 1) Package C should be installed if both package A and be are B are installed (because of user expectations; A implies that it will use the functionality of B, if present, but that requires C) 2) Package C depends on A and B packages that supply block devices: usb-storage, sdcard, ... autoselect packages that are needed to use these: e.g. block-mount block-mount is *required* to use usb, it's just nice to have. That's why profile selection not autoselect. What do you mean? block-mount is *required* to use usb,
Re: [OpenWrt-Devel] [PATCH] Automount enhanced/fixed, also fstab
On Fri, 2010-02-19 at 19:42 +0100, edgar.sol...@web.de wrote: [extroot support split into lots of small packages] Imho for stuff like blkid the packaging overhead is higher than enabling the corresponding busybox applet - the package status info plus control file plus conditionals introduced elsewhere to check for the existance of a blkid executable is probably higher than the few hundred additional bytes of binary code introduced by enabling the busybox feature. I do not know whether we do ordinary users a favor by introducing dozens of microscopic packages just to allow some power users to get rid of a few features they don't want. I'd agree with an extroot-base and extroot-extra package maybe but not splitting each possibility out of the construct. well, How about one big additional storage package then? Additionally enabling swapon and blkid from busybox? This also makes it easier to maintain. There is enough stuff already in base files. One or two packages is the solution we'll be going for, with swapon and blkid enabled in busybox. This makes things a whole lot easier in terms of the code as well as the packaging. In my opinion most users want a proven solution with a defined feature set that implements the current best practices. If somebody wants to Agreed. implement external rootfs with the least amount of flash space he can select the tools he need manually and grab the script of the day from the wiki or some random blog. Only if he can disable the blownup/unfitting/readymade package before, so that he has got the space and not lots of files cluttering his system. I don't see why we can't just agree on some standard, say for example ext2 rootfs with ext2 fsck and blkid support. Whoever needs something else is free to create his own solution. That's a different topic. A default configuration for ext rootfs makes absolute sense. How would you expect the external media to be initialized (formatted)? I am not sure it is a good idea to let the router do it during firstboot. On the other hand image download users probably don't have a I'm making that an optional feature. But the recommended way for most users is to boot a normal jffs2-based session (which is also the fallback in case of problems mounting the external rootfs) and use the scripts I will be writing, to initialize the rootfs, and then reboot into the rootfs. -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] External Rootfs (e.g. USB)
On Fri, 2010-02-19 at 00:19 -0500, Stefan Monnier wrote: This has to be manually configured after the first boot (and requires a reboot after a sysupgrade first boot). H... that's a problem. It means that you can't just have squashfs+extroot but need a jffs2 inbetween just for this little cconfig. Actually the squashfs/jffs2 is a fallback full firmware in the event of Inevitable Disaster(tm). Still, you need jffs2 there (both the jffs2 partition and the jffs2 modules). That's a lot of flash space for something that's not actually needed. And of course, it's also an added step when installing upgrading the firmware. Having a fallback jffs2 is something most people have said they think is required. config 'modules' 'modules' list 'fs_modules' 'fs-ext3' list 'controller' 'usb-core' list 'controller' 'usb-ohci' list 'controller' 'usb-storage' In my (limited experience), load all the available modules works just dandy: after all, these are only the modules available in the proto-root filesystem, so they're likely to be pretty close to the bare minimum. Could you explain the rationale for the relatively sophisticated config of modules you're proposing here? actually, the squashfs is likely to contain much more than the bare minimum; Why? If your rootfs is on USB or some such, there's little point in including lots of stuff in your squashfs. Again, popular request is for a fallback jffs2. it's got whatever the user menuconfig selects as their base router configuration and it's harder to do something about things going wrong in preinit, so minimizing the modules loaded is useful. In addition hotplug doesn't coldplug in init. That means hotplug events aren't generated unless the modules are loaded after hotplug (in /etc/init.d/boot). I'll take your word for it on these issues. They haven't affected me, but that's not statistically significant. And, finally, it's really not very sophisticated. It just loads modules if they're listed, the same was as load_modules for the main system does, except it loads specific modules instead of all available. Well, I'm looking at it from the point of view of a user who'd like to be able to directly tell make menuconfig that his rootfs is on /dev/hde1, in which case any configuration on top of the rootfs device name is an annoyance. Having an automatic configuration option is something I intend to have, however it won't be the default, because it's not as safe. It's not terribly complicated code in my opinion, so shouldn't be a problem. I meant complex for the user, not for the implementer. I mean, as a user, I've already had to select which modules to include in my squashfs so that my rootfs can be found, so writing this file is an annoyance, and will hold redundant info, except that I additionally have to figure out whether it should say fs_modules or controller or maybe something else. Well Felix has suggested a way of dealing with this, so that we don't need the modules, or for that matter a config file separate from /etc/config/fstab -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 2mb flash not OpenWRT-Target?
On Fri, 2010-02-19 at 18:05 +0100, edgar.sol...@web.de wrote: obviously. DD-WRT micro images also run on 2MB devices, see for contained functionality http://dd-wrt.com/wiki/index.php/What_is_DD-WRT%3F#File_Versions , so why should openwrt fail to do so? I already compiled images smaller than 2MB. Functionality was limited of course. The OpenWRT core devs have made a decision to not pursue the 2/8 option. That's why I recommend a sister project. Not to say, G'way kid, but rather to have project, that incorporates updates from OpenWRT for bug fixes, etc, but starts from the ground up by choosing the small option over the featureful option. You can strip busybox and the kernel more than OpenWRT does, as well as base-files. If you define the functionality you expect to support and make your configuration/coding decisions based on that, you can end up with a much more optimal solution for tiny routers then by hacking on a firmware that expects a minimum of 4MB. In other words I think it'd be better, if you want an effective 2MB router, to build for 2MB routers from the beginning, rather than hacking bits off a 4MB+ firmware. Regards, Daniel -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Automount enhanced/fixed, also fstab
On Sat, 2010-02-20 at 13:13 +0100, edgar.sol...@web.de wrote: well, How about one big additional storage package then? Additionally enabling swapon and blkid from busybox? This also makes it easier to maintain. There is enough stuff already in base files. One or two packages is the solution we'll be going for, with swapon and blkid enabled in busybox. This makes things a whole lot easier in terms of the code as well as the packaging. This is very close to your current packaging. You probably want to make these changes yourself? Working on it now. I'm making that an optional feature. But the recommended way for most users is to boot a normal jffs2-based session (which is also the fallback in case of problems mounting the external rootfs) and use the scripts I will be writing, to initialize the rootfs, and then reboot into the rootfs. How about a fs label openwrt-root-ext2? The fs suffix can tell what fs the block device is, and does not have to be ext2. Also the user obviously has to name the fs, what he wouldn't do if he didn't want the device to be an openwrt-root, so he can be explained. The biggest problem isn't being able to boot with a predefined rootfs, but making sure it has the right files for the image that's just been flashed (for instance). At some point preparing the filesystem has to be done, and it has to be loaded with the right binaries for the image that will be booting. This is trickier than it sounds if you want to be safe about it. If a device with a partition named 'openwrt-root-fs' (e.g. openwrt-root-ext2) is found during boot, openwrt will try to changeroot into it. Something like that. Certainly a label or uuid is possible, but the problem isn't convincing OpenWRT to boot into a rootfs, but making sure the rootfs has the appropriate binaries. That's why even if I use something like this for the autoconfigured rootfs (that basically does with a usb rootfs what now happens with jffs), it won't be the default - Not wiping at the wrong time and only on a flash is trickier than it sounds. And one other thing. Why don't you put extroot in buildroot/package/block-extroot. It seems pretty core to me :) and this way the connection to block-mount is more obvious. Hdepends on what the core devs say...I did it as a package because I have commit rights to the packages but not core OpenWRT. Nice work, ede Thank you. Regards, Daniel -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Hotplug / Init Race Conditions, Discussion
At http://wiki.openwrt.org/inbox/techref/taskinit_discussion I've tried to start a discussion of a solution to the problem of hotplug and init.d dependency / race condition problems that exist in OpenWRT today. If you have some ideas, please add to the page. Regards, Daniel -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] block-mount redux
Hi all,
Here is the promised rework of block-mount. It differs from the
previous version in the following ways:
* It has only two packages block-mount and block-hotplug
* block-mount automatically selects the Busybox blkid, mkswap, and
swapon/off.
* fsck functions are automatically added by the the fsck program's
package (e.g. e2fsprogs adds the block-mount/hotplug fsck checking for
ext2/3/4)
* it doesn't support automatic fsck of anonymous (not
in /etc/config/fstab) filesystems. The code to do it left in, but
commented out, as all it needs is for me to have the time to had fstype
detection to the busybox blkid code.
* it adds the is_rootfs option to mount config sections. If the
mount_by_section is called with find_rootfs, then *only* the rootfs is
mounted. This will be used by extroot. (extroot is not going to need a
separate config file)
--
Daniel Dickinson ddickin...@vertical.com
Contracted to Vertical Communications Inc.
Service Provider BU, Systems Developer
--
And that's my crabbing done for the day. Got it out of the way early,
now I have the rest of the afternoon to sniff fragrant tea-roses or
strangle cute bunnies or something. -- Michael Devore
GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org
The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com
Index: utils/btrfs-progs/files/btrfsck.sh
===
--- utils/btrfs-progs/files/btrfsck.sh (revision 0)
+++ utils/btrfs-progs/files/btrfsck.sh (revision 0)
@@ -0,0 +1,27 @@
+#!/bin/sh
+# Copyright (C) 2010 Vertical Communications
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+
+
+fsck_btrfsck() {
+ btrfsck -p $device 21 | logger -t fstab: btrfsck ($device)
+ local status=$?
+ case $status in
+ 0|1) ;; #success
+ 2) reboot;;
+ 4) echo btrfsck ($device): Warning! Uncorrected errors.| logger -t 'fstab'
+ return 1
+ ;;
+ *) echo btrfsck ($device): Error $status. Check not complete. | logger -t 'fstab';;
+ esac
+ return 0
+}
+
+fsck_btrfs() {
+ fsck_btrfsck $@
+}
+
+append libmount_known_fsck btrfs
+
Index: utils/btrfs-progs/Makefile
===
--- utils/btrfs-progs/Makefile (revision 19783)
+++ utils/btrfs-progs/Makefile (working copy)
@@ -1,6 +1,7 @@
#
# Copyright (C) 2009 OpenWrt.org
#
+# Copyright 2010 Vertical Communications
# This is free software, licensed under the GNU General Public License v2.
# See /LICENSE for more information.
#
@@ -48,6 +49,9 @@
define Package/btrfs-progs/install
$(INSTALL_DIR) $(1)/usr/bin
$(INSTALL_BIN) $(addprefix $(PKG_INSTALL_DIR)/usr/bin/, $(progs)) $(1)/usr/bin/
+ $(INSTALL_DIR) $(1)/lib/functions/fsck
+ $(INSTALL_BIN) ./files/btrfsck.sh $(1)/lib/functions/fsck/
endef
$(eval $(call BuildPackage,btrfs-progs))
+
Index: utils/reiserfsprogs/files/reiserfsck.sh
===
--- utils/reiserfsprogs/files/reiserfsck.sh (revision 0)
+++ utils/reiserfsprogs/files/reiserfsck.sh (revision 0)
@@ -0,0 +1,26 @@
+#!/bin/sh
+# Copyright 2010 Vertical Communications
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+
+fsck_reiserfsck() {
+ reiserfsck -p $device 21 | logger -t fstab: reiserfsck ($device)
+ local status=$?
+ case $status in
+ 0|1) ;; #success
+ 2) reboot;;
+ 4|6) echo reiserfsck ($device): Warning! Uncorrected errors.| logger -t fstab
+ return 1
+ ;;
+ *) echo reiserfsck ($device): Error $status. Check not complete. | logger -t fstab;;
+ esac
+ return 0
+}
+
+fsck_reiserfs() {
+ fsck_reiserfsck $@
+}
+
+append libmount_known_fsck reiserfs
+
Index: utils/reiserfsprogs/Makefile
===
--- utils/reiserfsprogs/Makefile (revision 19783)
+++ utils/reiserfsprogs/Makefile (working copy)
@@ -1,6 +1,6 @@
#
# Copyright (C) 2006-2009 OpenWrt.org
-#
+# Copyright 2010 Vertical Communications
# This is free software, licensed under the GNU General Public License v2.
# See /LICENSE for more information.
#
@@ -38,6 +38,9 @@
$(INSTALL_BIN) $(foreach bin,debugreiserfs mkreiserfs reiserfsck reiserfstune resize_reiserfs,$(PKG_INSTALL_DIR)/usr/sbin/$(bin)) $(1)/usr/sbin/
ln -sf mkreiserfs $(1)/usr/sbin/mkfs.reiserfs
ln -sf reiserfsck $(1)/usr/sbin/fsck.reiserfs
+ $(INSTALL_DIR) $(1)/lib/functions/fsck
+ $(INSTALL_BIN) ./files/reiserfsck.sh $(1)/lib/functions/fsck/
endef
$(eval $(call BuildPackage,reiserfsprogs))
+
Index: utils/dosfstools/files/dosfsck.sh
===
--- utils/dosfstools/files/dosfsck.sh (revision 0)
+++ utils/dosfstools/files/dosfsck.sh (revision 0)
@@ -0,0 +1,31 @@
+#!/bin/sh
+# Copyright 2010 Vertical Communications
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE
Re: [OpenWrt-Devel] [PATCH] block-mount with fix for extroot
I modified this slightly to add something I forgot I needed for extroot.
Namely the returning of the rootfs mount target, when we are searching
for a rootfs in mount_by_section.
--
And that's my crabbing done for the day. Got it out of the way early,
now I have the rest of the afternoon to sniff fragrant tea-roses or
strangle cute bunnies or something. -- Michael Devore
GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org
The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com
Index: package/block-mount/files/fsck.sh
===
--- package/block-mount/files/fsck.sh (revision 0)
+++ package/block-mount/files/fsck.sh (revision 0)
@@ -0,0 +1,74 @@
+#!/bin/sh
+# Copyright 2010 Vertical Communications
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+
+# There is some commented out code that can be added back once busybox blkid has
+# fstype detection added to it. util-linux blkid already does support this, if
+# a user wants to use it and uncomment this code.
+
+libmount_fsck() {
+ local device=$1
+ local fstype=$2
+ local fsck_enabled=$3
+# local blkid_fstype_match=$4
+ local known_type
+ local found_fsck=0
+
+
+# fsck_type=`libmount_fsck_fs_type $device $fstype $blkid_fstype_match`
+ fsck_type=$fstype
+
+ [ -n $fsck_type ] [ $fsck_type != swap ] {
+ grep -q $device /proc/swaps || grep -q $device /proc/mounts || {
+ [ -e $device ] [ $fsck_enabled -eq 1 ] {
+for known_type in $libmount_known_fsck; do
+ if [ $known_type = $fstype ]; then
+ fsck_${known_type} $device
+ found_fsck=1
+ break
+ fi
+done
+if [ $found_fsck -ne 1 ]; then
+ logger -t 'fstab' Unable to check/repair $device; no known fsck for filesystem type $fstype
+fi
+ }
+ }
+ }
+}
+
+#libmount_fsck_fs_type() {
+# local device=$1
+# local fstype=$2
+# local blkid_fstype_match=$3
+# local TYPE
+# local echo_type=
+#
+# eval $(blkid -s TYPE $device | cut -f2 -d:)
+#
+# if [ $fstype = ] [ $blkid_fstype_match -eq 0 ]; then
+# echo_type=$TYPE
+# elif [ $blkid_fstype_match -eq 0 ]; then
+# echo_type=$fstype
+# elif [ $fstype = $TYPE ]; then
+# echo_type=$TYPE
+# if [ -n $fstype ]; then
+# # extX detection may detect a lower level than is actually on the device
+# # additionally we may be forcing a higher level to be mounted as a lower level
+# if [ $fstype = ext4 ] || [ $fstype = ext3 ] || [ $fstype = ext2 ]; then
+# if [ $TYPE = ext2 ] || [ $TYPE = ext3 ] || [ $TYPE = ext4 ]; then
+#echo_type=$fstype
+# fi
+# fi
+# else
+# logger -t 'fstab' fsck: Specified filesystem type $fstype does not match detected filesystem type $TYPE
+# fi
+# echo $echo_type
+# return 0
+#}
+
+libmount_known_fsck=
+
+include /lib/functions/fsck
+
Index: package/block-mount/files/fstab.init
===
--- package/block-mount/files/fstab.init (revision 0)
+++ package/block-mount/files/fstab.init (revision 0)
@@ -0,0 +1,57 @@
+#!/bin/sh /etc/rc.common
+# Copyright (C) 2007 OpenWrt.org
+# Copyright (C) 2010 Vertical Communications
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+
+
+START=20
+
+. /lib/functions/mount.sh
+
+do_mount() {
+ local cfg=$1
+ config_mount_by_section $cfg
+}
+
+do_swapon() {
+ local cfg=$1
+ config_swapon_by_section $cfg
+}
+
+do_unmount() {
+ local cfg=$1
+
+ config_get target $cfg target
+ config_get_bool enabled $cfg enabled '1'
+ [ -n $target -a $enabled -gt 0 ] || return 0
+ umount $target
+}
+
+do_swapoff() {
+ local cfg=$1
+
+ config_get device $cfg device
+ config_get_bool enabled $cfg enabled '1'
+ [ -n $device -a $enabled -gt 0 ] type swapoff /dev/null || return 0
+ swapoff $device
+}
+
+start() {
+ config_load fstab
+ mkdir -p /var/lock
+ lock /var/lock/fstab.lck
+ echo '# WARNING: this is an auto generated file, please use uci to set defined filesystems' /etc/fstab
+ lock -u /var/lock/fstab.lck
+ config_foreach do_mount mount
+ config_foreach do_swapon swap
+}
+
+stop() {
+ config_load fstab
+ config_foreach do_unmount mount
+ config_foreach do_swapoff swap
+ swapoff -a
+}
+
Index: package/block-mount/files/block.sh
===
--- package/block-mount/files/block.sh (revision 0)
+++ package/block-mount/files/block.sh (revision 0)
@@ -0,0 +1,281 @@
+#!/bin/sh
+# Copyright 2010 Vertical Communications
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+
+. /etc/functions.sh
+
+reset_block_cb() {
+ mount_cb() {
+ dmc_mount_cfg=$1
+ shift # skip optional param
+ dmc_target=$2
+ dmc_mount_device=$3
+ dmc_fstype=$4
+ dmc_options=$5
+ dmc_enabled=$6
+ dmc_enabled_fsck=$7
+ dmc_uuid=$8
+ dmc_label=$9
+ shift
+ dmc_is_rootfs=$9
+ shift
+ dmc_blkid_fstype_match=$9
