Re: [OpenWrt-Devel] [PATCH] update usb-modeswitch-data to make it compile again
On Tuesday 16 August 2011 02:05:13 Hanno Schupp wrote: The update is required as the old filename usb-modeswitch-data-20110705.tar.bz2 is no longer hosted on http://www.draisberghof.de/usb_modeswitch/ BTW, the two openwrt.org backup servers do not hold either the old usb-modeswitch-data-20110705.tar.bz2 nor the new usb-modeswitch-data-20110805.tar.bz2 In effect there is a dependency on one external server. If they decide to change to a new version and not continue hosting the old, the compilation breaks. The sources on the openwrt,org servers should therefore be urgently updated. Signed-off-by: Your name hanno.sch...@gmail.com Applied in r28103, thanks! -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] update usb-modeswitch to 1.1.19
On Tuesday 16 August 2011 03:05:16 Hanno Schupp wrote: Signed-off-by: Your name hanno.sch...@gmail.com Applied in r28104, thanks! -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] usb_modeswitch version bump
On Friday 26 August 2011 23:40:15 Alexander Khryukin wrote: Good day usb_modeswitch version bump feeds/packages/utils/usb-modeswitch Both applied in r28103 and r28104, thanks! -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] New package simplejson
On Thursday 25 August 2011 13:01:26 Roberto Riggio wrote: THe simplejson is a json encoder/decoder for python it is a lot faster (close to 10x) than the json module that ships with python. A special thanks to Jan Willies for the feedback on the distribute package. Signed-off-by: Roberto Riggio roberto.rig...@create-net.org Applied in r28105, thanks! Your patch was line-wrapping damaged, this is not the first time, fix your mailer or use git-send-email. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RESEND] Platform patches not applied on make toolchain/kernel-headers/prepare
Hello, On Monday 29 August 2011 10:22:47 Emmanuel Deloget wrote: Apologies if you receive this twice. It was supposed to be sent on last friday, but it seems it wasn't - or at least, I didn't got it back - which is weird since I didn't lost any other message. It was, see my reply on the list and to you [1]. Note that your email addressed bounced on Friday. [1]: https://lists.openwrt.org/pipermail/openwrt-devel/2011-August/012031.html ---8- Hello, I'm not sure whether this is by design or if this is a mistake, but when one does a make toolchain/kernel-headers/prepare the build process applies the generic patches (in $(GENERIC_PLATFORM_DIR)/paches-$(KERNEL_VERSION)) but not the ones that are located in the specific platform subtree. This has an undesireable consequence: when one wants to modify a linux header that can be used by some userspace program, he must add its platform-specific patch in the generic subtree - otherwise the changes to the header file are not visible. The same remark applies for the platfom files/ directory, which contains potentially important header files as well. In my opinion, the kernel-headers toolchain package shall have no patches/ and no files/ - that doesn't make much sense. I cannot see any reason were one would want to have user-space kernel header files that are not tied to the kernel-space ones. Since the patches are applied on the linux tree, they should be added into to linux generic patch dir (same remark for the files), so maybe one can just set PATCH_DIR to $(PLATFORM_DIR)/patches-$(KERNEL_VERSION) (or something like that) in kernel-headers/Makefile - or change the Kernel/Patch/Default rule so that it always apply the platform patches - and not the patches in PATCH_DIR (since this variable depends on the package). So, honnest mistake or design choice? (i.e. what should I do with this report?) Best regards, -- Emmanuel Deloget ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/6] kernel: add some missing usb modules
Hello, On Monday 29 August 2011 22:11:51 eugene...@gmail.com wrote: From: Eugene San (eugenesan) eugene...@gmail.com Signed-off-by: Eugene San (eugenesan) eugene...@gmail.com --- target/linux/generic/config-3.0 |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) Any reasons this is not applied to config-3.1 as well? diff --git a/target/linux/generic/config-3.0 b/target/linux/generic/config-3.0 index ed8ad82..d8bd005 100644 --- a/target/linux/generic/config-3.0 +++ b/target/linux/generic/config-3.0 @@ -2893,13 +2893,13 @@ CONFIG_USB_SERIAL_SAFE_PADDED=y # CONFIG_USB_STKWEBCAM is not set # CONFIG_USB_STORAGE is not set CONFIG_USB_STORAGE_ALAUDA=y -# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set -# CONFIG_USB_STORAGE_ENE_UB6250 is not set +CONFIG_USB_STORAGE_CYPRESS_ATACB=y +CONFIG_USB_STORAGE_ENE_UB6250=y CONFIG_USB_STORAGE_DATAFAB=y # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_REALTEK is not set CONFIG_USB_STORAGE_FREECOM=y -# CONFIG_USB_STORAGE_ISD200 is not set +CONFIG_USB_STORAGE_ISD200=y CONFIG_USB_STORAGE_JUMPSHOT=y CONFIG_USB_STORAGE_KARMA=y # CONFIG_USB_STORAGE_ONETOUCH is not set -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/6] kernel: allow parallel build of image and modules
Hello, On Monday 29 August 2011 22:11:52 eugene...@gmail.com wrote: From: Eugene San (eugenesan) eugene...@gmail.com Signed-off-by: Eugene San (eugenesan) eugene...@gmail.com --- Config.in | 13 + include/kernel-defaults.mk |6 -- 2 files changed, 17 insertions(+), 2 deletions(-) We already support building the kernel and modules in parallel when make is invoked with a given number of jobs from the top-level directory of OpenWrt. Did not you have it working? diff --git a/Config.in b/Config.in index f36221c..f4dbf80 100644 --- a/Config.in +++ b/Config.in @@ -307,6 +307,19 @@ menu Global build settings If you say Y, toolchain build might break. Before reporting build bugs, set this to N and re-run the build. + config KERNEL_PARALLEL + bool + prompt Parallelize the kernel build (May break build) + depends on PKG_BUILD_PARALLEL + default n + help + Build the kernel with parallel make jobs. + This speeds up the kernel build on SMP machines, but may + break the build for certain toolchain versions. + + If you say Y, kernel build might break. + Before reporting build bugs, set this to N and re-run the build. + comment Stripping options choice diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk index 5fd27ae..b637577 100644 --- a/include/kernel-defaults.mk +++ b/include/kernel-defaults.mk @@ -5,6 +5,8 @@ # See /LICENSE for more information. # +KERNEL_JOBS?=$(if $(CONFIG_KERNEL_PARALLEL),-j$(CONFIG_PKG_BUILD_JOBS)) + KERNEL_MAKEOPTS := -C $(LINUX_DIR) \ CROSS_COMPILE=$(KERNEL_CROSS) \ ARCH=$(LINUX_KARCH) \ @@ -93,14 +95,14 @@ endef define Kernel/CompileModules/Default rm -f $(LINUX_DIR)/vmlinux $(LINUX_DIR)/System.map - +$(MAKE) $(KERNEL_MAKEOPTS) modules + +$(MAKE) $(KERNEL_MAKEOPTS) $(KERNEL_JOBS) modules endef OBJCOPY_STRIP = -R .reginfo -R .notes -R .note -R .comment -R .mdebug -R .note.gnu.build-id define Kernel/CompileImage/Default $(if $(CONFIG_TARGET_ROOTFS_INITRAMFS),,rm -f $(TARGET_DIR)/init) - +$(MAKE) $(KERNEL_MAKEOPTS) $(KERNELNAME) + +$(MAKE) $(KERNEL_MAKEOPTS) $(KERNEL_JOBS) $(KERNELNAME) $(KERNEL_CROSS)objcopy -O binary $(OBJCOPY_STRIP) -S $(LINUX_DIR)/vmlinux $(LINUX_KERNEL) $(KERNEL_CROSS)objcopy $(OBJCOPY_STRIP) -S $(LINUX_DIR)/vmlinux $(KERNEL_BUILD_DIR)/vmlinux.elf endef -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 6/6] [package] mac80211: fix mwl8k firmware treatment at build and run times
Hello,
On Monday 29 August 2011 22:11:55 eugene...@gmail.com wrote:
From: Eugene San (eugenesan) eugene...@gmail.com
Signed-off-by: Eugene San (eugenesan) eugene...@gmail.com
---
package/mac80211/Makefile |4 +-
.../701-mwl8k-firmware-reload-workaround.patch | 29
2 files changed, 31 insertions(+), 2 deletions(-)
create mode 100644
package/mac80211/patches/701-mwl8k-firmware-reload-workaround.patch
The first patch looks obviously correct, what about sending the second
upstream?
diff --git a/package/mac80211/Makefile b/package/mac80211/Makefile
index e2942f8..3fdd691 100644
--- a/package/mac80211/Makefile
+++ b/package/mac80211/Makefile
@@ -1326,14 +1326,14 @@ define KernelPackage/ath9k-htc/install
endef
define KernelPackage/mwl8k/install
- $(INSTALL_DIR) $(1)/lib/firmware
+ $(INSTALL_DIR) $(1)/lib/firmware/mwl8k/
$(INSTALL_DATA) \
$(PKG_BUILD_DIR)/$(PKG_LINUX_FIRMWARE_SUBDIR)/mwl8k/fmimage_8366_ap-2.fw
\ $(PKG_BUILD_DIR)/$(PKG_LINUX_FIRMWARE_SUBDIR)/mwl8k/fmimage_8366.fw \
$(PKG_BUILD_DIR)/$(PKG_LINUX_FIRMWARE_SUBDIR)/mwl8k/helper_8366.fw \
$(PKG_BUILD_DIR)/$(PKG_LINUX_FIRMWARE_SUBDIR)/mwl8k/fmimage_8687.fw \
$(PKG_BUILD_DIR)/$(PKG_LINUX_FIRMWARE_SUBDIR)/mwl8k/helper_8687.fw \
- $(1)/lib/firmware/
+ $(1)/lib/firmware/mwl8k/
endef
define KernelPackage/net-ipw2100/install
diff --git
a/package/mac80211/patches/701-mwl8k-firmware-reload-workaround.patch
b/package/mac80211/patches/701-mwl8k-firmware-reload-workaround.patch new
file mode 100644
index 000..7c09699
--- /dev/null
+++ b/package/mac80211/patches/701-mwl8k-firmware-reload-workaround.patch
@@ -0,0 +1,29 @@
+--- a/drivers/net/wireless/mwl8k.c
b/drivers/net/wireless/mwl8k.c
+@@ -5470,7 +5470,7 @@
+ */
+ static int mwl8k_reload_firmware(struct ieee80211_hw *hw, char *fw_image)
+ {
+-int i, rc = 0;
++int i, rc, loops = 0;
+ struct mwl8k_priv *priv = hw-priv;
+
+ mwl8k_stop(hw);
+@@ -5479,7 +5479,16 @@
+ for (i = 0; i mwl8k_tx_queues(priv); i++)
+ mwl8k_txq_deinit(hw, i);
+
+-rc = mwl8k_init_firmware(hw, fw_image, false);
++loops = 5;
++do {
++rc = mwl8k_init_firmware(hw, fw_image, false);
++if (rc)
++printk(KERN_WARNING mwl8k: Failed to init firmware,
will retry
in 5
seconds @%s:%d.\n, __FUNCTION__, __LINE__); ++ else
++break;
++
++msleep(5000);
++} while (--loops);
+ if (rc)
+ goto fail;
+
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 5/5] [packages] samba3: update version to 3.0.47 Thanks to Maarten Bezemer m.m.beze...@utwente.nl
Hello, On Tuesday 30 August 2011 10:56:17 Maarten Bezemer wrote: Hello, I have some additional changes since the last version (v4) of my patch, according to the comments of Cezary Jackiewicz (of 14 Augustus 2011). I also added (better) support for iconv to smaba3. Besides, I would like to give you credit for this patch, so I will take your version instead. I tested them yesterday briefly on my router. Hopefully, I have some time to test them somewhat better soon (especially the iconv support, of which I do not really know how to test yet). Then I'll send another update of my samba3 patch to the list and await further comments... ;) Sounds, good, thanks Maarten. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] usb on Asus WL500gPv2 not working
Hello, On Wednesday 31 August 2011 13:29:45 Alexander Gordeev wrote: Hi! Usb ports on my Asus WL500gPv2 do not work with the latest trunk. I tried to build a fresh checkout. Full log is attached. Here is what I think is the problem: usb 1-1: device descriptor read/64, error -62 usb 1-1: device descriptor read/64, error -62 usb 1-1: new full speed USB device number 3 using ohci_hcd usb 1-1: device descriptor read/64, error -62 usb 1-1: device descriptor read/64, error -62 usb 1-1: new full speed USB device number 4 using ohci_hcd usb 1-1: device not accepting address 4, error -62 usb 1-1: new full speed USB device number 5 using ohci_hcd usb 1-1: device not accepting address 5, error -62 hub 1-0:1.0: unable to enumerate USB device on port 1 What can I do to fix this? Are you sure this is not an issue with the USB slave device? It looks to me like the device might not be responding correctly, or maybe it's drowing too much power. This could be a genuine ssb-ohci bug anyway. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] replace CONFIG_PREEMPT_NONE with CONFIG_PREEMPT
Hello, On Friday 02 September 2011 00:55:54 Luka Perkov wrote: I also had this issue on my sx763 lantiq based board: https://dev.openwrt.org/ticket/9440 With symbol table I got this oops: Unhandled kernel unaligned access[#1]: ... bla bla bla (to keep it short) ... Call Trace: [80cb8968] nf_nat_setup_info+0x2e0/0x6e8 [nf_nat] [80d1e158] masquerade_tg+0xc0/0xe8 [ipt_MASQUERADE] [80c646a8] ipt_do_table+0x3e0/0x484 [ip_tables] [80dee0c0] nf_nat_rule_find+0x28/0x9c [iptable_nat] [80dee290] nf_nat_fn+0x120/0x1a0 [iptable_nat] [801baa34] nf_iterate+0x8c/0xfc [801bab34] nf_hook_slow+0x90/0x17c [801c76c8] ip_output+0xd8/0x104 [8019a224] __netif_receive_skb+0x4d4/0x578 [80210128] br_handle_frame+0x280/0x2b8 [80199f9c] __netif_receive_skb+0x24c/0x578 [8019a370] process_backlog+0xa8/0x188 [8019a778] net_rx_action+0x8c/0x1b8 [800215f0] __do_softirq+0xa8/0x154 [800217f0] do_softirq+0x48/0x68 [800031c0] plat_irq_dispatch+0xf4/0x164 [800059ec] ret_from_irq+0x0/0x4 [80005be0] r4k_wait+0x20/0x40 [80007690] cpu_idle+0x28/0x4c [802a58d0] start_kernel+0x35c/0x378 It's easy to reproduce with nmap: # nmap -sT -p 1-1 -T insane -Pn -n some.public.ip.address/24 After some time I discovered that the issue is in this lines: % sed -n '320,326p' linux-2.6.39.4/net/ipv4/netfilter/nf_nat_core.c spin_lock_bh(nf_nat_lock); /* nf_conntrack_alter_reply might re-allocate exntension aera */ nat = nfct_nat(ct); nat-ct = ct; hlist_add_head_rcu(nat-bysource, net-ipv4.nat_bysource[srchash]); spin_unlock_bh(nf_nat_lock); Long story short - enable CONFIG_PREEMPT to have functional spin locks: http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/x109.htm l Also in linux-2.6.39.4/kernel/Kconfig.preempt you will see for CONFIG_PREEMPT: Select this if you are building a kernel for a desktop or embedded system with latency requirements in the milliseconds range Because of that I made changes to all kernel config files. Signed-off-by: Luka Perkov openwrt --to-- lukaperkov.net I am not opposed to enabling CONFIG_PREEMPT on a global basis, but I am afraid this might reveal new locking problems that we have not had so far. At least trunk should be the place where to experiment this. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] replace CONFIG_PREEMPT_NONE with CONFIG_PREEMPT
On Friday 02 September 2011 12:55:08 Geert Uytterhoeven wrote: On Fri, Sep 2, 2011 at 12:39, Luka Perkov open...@lukaperkov.net wrote: On Fri, Sep 02, 2011 at 10:46:37AM +0200, Florian Fainelli wrote: On Friday 02 September 2011 00:55:54 Luka Perkov wrote: Also in linux-2.6.39.4/kernel/Kconfig.preempt you will see for CONFIG_PREEMPT: Select this if you are building a kernel for a desktop or embedded system with latency requirements in the milliseconds range Please look at the kernel config file above. You will see that CONFIG_PREEMPT should be used on embedded systems... ... with latency requirements in the milliseconds range. Indeed, that's the part I am concerned with, along with the memory footprint. Any code should be able to work with and without Preemption enabled. Your patch remains a workaround for now. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] replace CONFIG_PREEMPT_NONE with CONFIG_PREEMPT
On Friday 02 September 2011 15:10:47 Luka Perkov wrote: On Fri, Sep 02, 2011 at 01:32:18PM +0200, Florian Fainelli wrote: On Friday 02 September 2011 12:55:08 Geert Uytterhoeven wrote: On Fri, Sep 2, 2011 at 12:39, Luka Perkov open...@lukaperkov.net wrote: On Fri, Sep 02, 2011 at 10:46:37AM +0200, Florian Fainelli wrote: On Friday 02 September 2011 00:55:54 Luka Perkov wrote: Also in linux-2.6.39.4/kernel/Kconfig.preempt you will see for CONFIG_PREEMPT: Select this if you are building a kernel for a desktop or embedded system with latency requirements in the milliseconds range Please look at the kernel config file above. You will see that CONFIG_PREEMPT should be used on embedded systems... ... with latency requirements in the milliseconds range. Indeed, that's the part I am concerned with, along with the memory footprint. Any code should be able to work with and without Preemption enabled. Your patch remains a workaround for now. Please try to reproduce the issue with nmap on your devices. Run nmap like I wrote on your PC and see what will your router do (you are testing it's ability to handle many nat connections). I will try to reproduce the error, but you cannot argue that code should be able to work fine with PREEMPT enabled or not, I have seen crappy drivers only working with preemption enabled too, but this is not an excuse. Try it with and without my patch and post what happened. This has a net impact on the resulting kernel size, here is what I get for ar7: - without preempt: 887 KB vmlinux.lzma - with preempt: 902 KB vmlinux.lzma this is quite a big increase. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] replace CONFIG_PREEMPT_NONE with CONFIG_PREEMPT
On Sunday 04 September 2011 22:44:08 Luka Perkov wrote: On Sun, Sep 04, 2011 at 08:47:46PM +0200, Michael Büsch wrote: On Sun, 4 Sep 2011 01:06:02 +0200 Luka Perkov open...@lukaperkov.net wrote: What are you actually trying to fix with enabling preemption? I didn't really get it by reading your mail. Kernel oops that I described. Yeah. And that is completely unacceptable. See the patch attached. CONFIG_PREEMPT must be enabled; don't know what more I can do. No. You must provide a full OOPS message. An unaligned access is easy to fix (or at least work around properly) with proper debugging information. Unhandled kernel unaligned access[#1]: Cpu 0 $ 0 : 0006 0011 $ 4 : d5bf9da3 80dbb548 0006 c010 $ 8 : c578 6e617332 6e617332 $12 : $16 : 6fbb5ff7 80d05618 8028fab0 $20 : 8028fa28 80cba248 8028fabc 8028fabe $24 : 80d85a50 $28 : 8028e000 8028f9f0 81043d14 80cb8708 Hi: 0235 Lo: 02922c00 epc : 80cb8968 nf_nat_setup_info+0x2e0/0x6e8 [nf_nat] Tainted: P ra: 80cb8708 nf_nat_setup_info+0x80/0x6e8 [nf_nat] Status: 1100fc03KERNEL EXL IE Cause : 00800010 BadVA : 6fbb600f PrId : 00019641 (MIPS 24Kc) Modules linked in: gpio_keys_polled dwc_otg ath_pci ath_hal(P) lantiq_atm drv_dsl_cpe_api lantiq_mei ipt_MASQUERADE iptable_nat nf_nat xt_conntrack xt_NOTRACK iptable_raw xt_state nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack pppoe pppox ipt_REJECT xt_TCPMSS ipt_LOG xt_comment xt_multiport xt_mac xt_limit iptable_mangle iptable_filter ip_tables xt_tcpudp x_tables ppp_async ppp_generic slhc br2684 atm drv_vmmc usbcore drv_tapi crc_ccitt drv_ifxos arc4 aes_generic crypto_algapi Process swapper (pid: 0, threadinfo=8028e000, task=80291bc0, tls=) Stack : 81722280 8019bfa0 801c686c 80f4f800 c0a801c7 c5780002 6ea9cbd9 a6a90600 d5bf9da3 6ea9cbd9 a6a90002 c0a801c7 c5780601 80cb9fd0 80cb8b0c 0001 d5bf9da3 c0a801c7 8028fae4 80fd8840 80d05618 8028fae8 d8263338 813ca98c 80fd8840 ... Call Trace: [80cb8968] nf_nat_setup_info+0x2e0/0x6e8 [nf_nat] [80d1e158] masquerade_tg+0xc0/0xe8 [ipt_MASQUERADE] [80c646a8] ipt_do_table+0x3e0/0x484 [ip_tables] [80dee0c0] nf_nat_rule_find+0x28/0x9c [iptable_nat] [80dee290] nf_nat_fn+0x120/0x1a0 [iptable_nat] [801baa34] nf_iterate+0x8c/0xfc [801bab34] nf_hook_slow+0x90/0x17c [801c76c8] ip_output+0xd8/0x104 [8019a224] __netif_receive_skb+0x4d4/0x578 [80210128] br_handle_frame+0x280/0x2b8 [80199f9c] __netif_receive_skb+0x24c/0x578 [8019a370] process_backlog+0xa8/0x188 [8019a778] net_rx_action+0x8c/0x1b8 [800215f0] __do_softirq+0xa8/0x154 [800217f0] do_softirq+0x48/0x68 [800031c0] plat_irq_dispatch+0xf4/0x164 [800059ec] ret_from_irq+0x0/0x4 [80005be0] r4k_wait+0x20/0x40 [80007690] cpu_idle+0x28/0x4c [802a58d0] start_kernel+0x35c/0x378 If you want to debug say so and I'll send you vmlinux file. I'm not going to debug this further. Then just post the oops along with the problem description the netfilter/netdev mailing-list and get the upstream networking people resolve this bug for you. They certainly will ask you to test for some patches, which sounds like an acceptable trade to me. Please at least agree that enabling preemption is a workaround and not a fix. --- a/net/ipv4/netfilter/nf_nat_core.c +++ b/net/ipv4/netfilter/nf_nat_core.c This doesn't seem to fix any alignment issues, does it? No. Users can now choose which preemption mode they want. Is this ok? Luka Index: Config.in === --- Config.in (revision 28166) +++ Config.in (working copy) @@ -231,6 +231,33 @@ bool Compile the kernel with SysRq support default n + choice + prompt Compile the kernel with selected preemption model + default KERNEL_PREEMPT_NONE + help + Select the preemption model you wish to use. + + config KERNEL_PREEMPT_NONE + bool No Forced Preemption (Server) + help + Select this option if you are building a kernel for a server or + scientific/computation system, or if you want to maximize the + raw processing power of the kernel, irrespective of scheduling + latencies. + + config KERNEL_PREEMPT_VOLUNTARY + bool Voluntary Kernel Preemption (Desktop) + help + Select this if you are building a kernel for a desktop system. + + config KERNEL_PREEMPT + bool Preemptible Kernel (Low-Latency Desktop) +
Re: [OpenWrt-Devel] Valgrind for MIPS
Hello, On Tuesday 06 September 2011 17:37:32 Raphaël HUCK wrote: Hi all, I've just stumbled upon a patch adding MIPS support to Valgrind. It is applicable for MIPS32r2 instruction set, and supports both little-endian and big-endian cores. It can be applied to the revision 11845 (version 3.7.0.SVN) from the main Valgrind trunk. However, as the Valgrind package in OpenWrt (https://dev.openwrt.org/browser/packages/utils/valgrind/Makefile) uses version 3.3.1, how is it possible to package Valgrind/MIPS for OpenWrt without conflicting with the existing package? I see no problems in providing a valgrind-svn package which is more up to date and on top of which we apply this patch. I do not know how many people could test this patch, but having it in OpenWrt would certainly increase the user base. For those who are interested in this patch, see https://bugs.kde.org/show_bug.cgi?id=270777#c12 I will give it a try in qemu tomorrow, thanks for keeping us posted with this useful patch. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] buildroot-ng
Hello, On Friday 09 September 2011 16:53:15 Roman Yeryomin wrote: On 6 September 2011 18:37, Roman Yeryomin leroi.li...@gmail.com wrote: Did anyone think of separating buildroot-ng from the content (packages and targets) into a separate project (under OpenWrt name of cause)? Then one can do something like `make content' and depending on what is configured get either openwrt or something else. Really noone? Well then how about not thinking but actually doing it? I already use it like that and thought that community could benefit from such approach too. This looks like a good idea, I am not sure about how many OpenWrt-specific stuff are folded into our build system, but if you have any patches to decouple OpenWrt-specificities from buildroot, feel free to get them posted. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar71xx: Stability issues on DIR-615 E4
Hello, On Friday 09 September 2011 19:54:47 Alexey Loukianov wrote: Good day to all, As I already had posted to the list, I'm experimenting with OpenWRT installation on my fresh-new DIR-615 rev. E4 box. Looks like that current trunk it is pretty unstable on it - I've got unexpected reboots or hangs at random intervals, varying from several minutes to the several hours. I suspect that the reboots are caused by kernel panic followed by hw reset from watchdog, but I hadn't been able to catch it with remote syslog. Every time it looks like everything is fine and then - kaboom - ssh connection get's dropped due to no response from the peer and I find the box being hanged or in process of rebooting itself. So, my questions are: a) Are there any users of DIR-615 E4 on the list experiencing similar troubles? b) What should I do to try to catch the kmesg at the hang/reboot moment? Should I solder in serial console connector and monitor for messages through it? Or maybe there's some other way like remote kernel debug utilities or something of that kind? You should be able to use the crashlog feature, which is a small ring-buffer in RAM holding kernel panics and such. Provided that the bootloader does not erase the contents of the RAM between two reboots, you can get this output by using: mount -t debugs /sys/kernel/debug cat /sys/kernel/debug/crashlog this should tell you what was the last cause of panic. Most essential is the (a) part of the question as the problem I face might be related to the possible damage the box might got while I've been soldering USB connector and several SMD resistors to its PCB. ATM I'm thinking about buying another DIR-615 E4 box just to check how does the virgin vanilla box behave under OpenWRT. Could be a good idea to make sure the hardware is not faulty. I doubt so, but maybe the board with USB has a different power supply circuitry to handle overcurrents and the powering of the USB devices? -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Valgrind for MIPS
Hello, On Tuesday 13 September 2011 12:27:16 Tanguy Bouzeloc wrote: Hello, I prepare a valgrind-mips package and it seems okay for bcm63xx target with uclibc. It requires gcc 4.4+ in order to build and I've to force -01 optimisation level (Os or -O2 eventually freeze gcc). Are you sure this is working? valgrind does not repport any memory allocation for me, which looks suspicious to me. This was tested on malta+uclibc. Otherwise, you can just provide a patch which updates the existing valgrind package, there is no need to create a specific valgrind-mips package. Thank you. Regards, Tanguy. On 09/06/2011 05:37 PM, Raphaël HUCK wrote: Hi all, I've just stumbled upon a patch adding MIPS support to Valgrind. It is applicable for MIPS32r2 instruction set, and supports both little-endian and big-endian cores. It can be applied to the revision 11845 (version 3.7.0.SVN) from the main Valgrind trunk. However, as the Valgrind package in OpenWrt (https://dev.openwrt.org/browser/packages/utils/valgrind/Makefile) uses version 3.3.1, how is it possible to package Valgrind/MIPS for OpenWrt without conflicting with the existing package? For those who are interested in this patch, see https://bugs.kde.org/show_bug.cgi?id=270777#c12 Thanks, -Raphael ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/4] bsdiff: add bsdiff package
On Wednesday 31 August 2011 09:51:15 Alexander Gordeev wrote: Signed-off-by: Alexander Gordeev lasa...@lvk.cs.msu.su --- Applied in r28230, thanks! -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 4/4] xdelta3: add xdelta3 package
On Wednesday 31 August 2011 09:51:16 Alexander Gordeev wrote: Signed-off-by: Alexander Gordeev lasa...@lvk.cs.msu.su --- Applied in r28231, thanks! -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] packages: add jansson JSON library
On Tuesday 06 September 2011 23:21:20 Roman Yeryomin wrote: Signed-off-by: Roman Yeryomin ro...@advem.lv -- Applied in r28233, thanks! -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/4] lrzsz: create extra symlinks for minicom
On Wednesday 31 August 2011 09:51:13 Alexander Gordeev wrote: Minicom wants rz/rx/rb when asked to transfer a file. Signed-off-by: Alexander Gordeev lasa...@lvk.cs.msu.su --- Applied in r28227, thanks! -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/4] bzip2: build libbz2 package
On Wednesday 31 August 2011 09:51:14 Alexander Gordeev wrote: Build libbz2 and make bzip2 depend on it. libbz2 is necessary for packaging bsdiff. Also update perl-compress-bzip2 package accordingly. Signed-off-by: Alexander Gordeev lasa...@lvk.cs.msu.su --- Applied in r28228 and r28229, thanks! -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar71xx: Stability issues on DIR-615 E4 - [RESOLVED]
Hello Alexey, On Wednesday 14 September 2011 03:08:17 Alexey Loukianov wrote: 13.09.2011 06:53, Alexey Loukianov wrote: Ok, I had managed to get the kernel panic dump, thx. to Florian Fainelli and his hint about /sys/kernel/debug/crashlog. To the tail of this message I attach oops logs either in vanilla state and parsed by ksymoops. I suspect that this oops might be the same as had been reported in ticket #10071 and fixed in r28213. Will check it and report back. So far so good. Firmware built against r28222 had been running on my dir-615-e4 box for about 22 hours without any issues. Looks like it was really the bug #10071 just like I had been suspecting. Florian, thanks again for your help, it would be extremely hard to debug this issue without your invaluable help. I just pointed you at the crashlog feature ;) glad that you have it working fine as expected now. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] maccalc: add option to read mac from temp file
On Friday 16 September 2011 16:51:16 Alexander Gordeev wrote: В Fri, 16 Sep 2011 17:41:37 +0300 Roman Yeryomin leroi.li...@gmail.com пишет: On 16 September 2011 01:40, Alexander Gordeev lasa...@lvk.cs.msu.su wrote: В Fri, 26 Aug 2011 04:30:43 +0300 Roman Yeryomin leroi.li...@gmail.com пишет: This method is much more stable than reading dd's output via stdin. What kind of problems do you have with piping dd's output to stdin? It outputs garbage very frequently and maccalc fails to convert the mac (and as a consequence uci-default script fails to set the real mac address). Try dd without piping to maccalc and you'll see. I've noticed this bug on ramips platform and can't say anything about other boards. Well, then this is probably a bug in dd? Or uClibc? Or kernel? Ok, I'll try to reproduce it. Can you please tell me what exactly is happening? What happens if you insert some proper fflush() in maccalc? -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files: load_kernelmodules()
On Tuesday 20 September 2011 13:32:52 Bastian Bittorf wrote:
I would rather let it accept an argument so the day we change the
path we
don't have to change the function and just replace occurences of
the script
instead.
Are you agree with patch6, which implements this?
I think patch 6 proposes too much configurability, so let's just do it that way
instead:
function load_modules() {
local dir=${1:-/etc/modules.d}
...
}
As far I can see, only one script (/etc/init.d/boot)
uses this function. Will this change in the future?
Probably not, it's just to be enough.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/5] [packages] rsync: cosmetic changes after package split
Hello, On Monday 29 August 2011 22:09:35 eugene...@gmail.com wrote: From: Eugene San (eugenesan) eugene...@gmail.com Signed-off-by: Eugene San (eugenesan) eugene...@gmail.com --- net/rsync/Makefile | 26 +- 1 files changed, 13 insertions(+), 13 deletions(-) diff --git a/net/rsync/Makefile b/net/rsync/Makefile index 46670e5..f6d8eb1 100644 --- a/net/rsync/Makefile +++ b/net/rsync/Makefile @@ -21,20 +21,20 @@ PKG_BUILD_PARALLEL:=1 include $(INCLUDE_DIR)/package.mk define Package/rsync - SECTION:=net - CATEGORY:=Network - SUBMENU:=File Transfer - TITLE:=Fast remote file copy program (like rcp) - DEPENDS:=+libpopt - URL:=http://rsync.samba.org/ + SECTION:=net + CATEGORY:=Network + SUBMENU:=File Transfer + TITLE:=Fast remote file copy program (like rcp) + DEPENDS:=+libpopt + URL:=http://rsync.samba.org/ endef define Package/rsyncd - SECTION:=net - CATEGORY:=Network - SUBMENU:=File Transfer - TITLE:=Rsync daemon - DEPENDS:=+rsync + SECTION:=net + CATEGORY:=Network + SUBMENU:=File Transfer + TITLE:=Rsync daemon + DEPENDS:=+rsync endef define Package/rsync/description @@ -54,7 +54,7 @@ CONFIGURE_ARGS += \ --disable-debug \ --disable-locale \ --disable-xattr-support \ - --disable-acl-support \ + --disable-acl-support define Package/rsync/install $(INSTALL_DIR) $(1)/usr/bin @@ -68,7 +68,7 @@ define Package/rsyncd/description endef define Package/rsyncd/conffiles -/etc/rsyncd.conf + /etc/rsyncd.conf endef define Package/rsyncd/install The prefered way of writing a Makefile is how it is right now. Inserting tabs instead of 2 spaces is not what we generally have. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] replace CONFIG_PREEMPT_NONE with CONFIG_PREEMPT
Hello, On Sunday 04 September 2011 21:24:45 Philip Prindeville wrote: On 9/4/11 11:43 AM, Michael Büsch wrote: On Sun, 04 Sep 2011 10:11:08 -0700 Philip Prindeville philipp_s...@redfish-solutions.com wrote: And finally, I'm not really convinced that any of the routers/APs that OpenWRT supports have latency requirements in the milliseconds range. I'd rather say throughput matters a _lot_ more than a millisecond of latency for these devices. If you're doing VoIP, then I'd certainly say latency matters. No it doesn't. At least not in the MILLISECONDS range. It does not matter at all, if your voip call has 300 or 302 ms latency. But it _does_ matter that there's enough throughput bandwidth to get most of the packages through the pipe. Who the heck has 300ms latency??? pbx*CLI sip show peers Name/username HostDyn Forcerport ACL Port Status ata_1/ata_1192.168.1.12 D N 5060 OK (15 ms) ata_2/ata_2 192.168.1.12 D N 5061 OK (11 ms) bedroom_1/bedroom_1192.168.1.5 D N 5060 OK (14 ms) bedroom_2/bedroom_2192.168.1.5 D N 5061 OK (13 ms) bedroom_3/bedroom_3 192.168.1.5 D N 5062 OK (16 ms) cell_1/cell_1 184.72.221.84D N 45983OK (211 ms) cell_2 (Unspecified) D N 0UNKNOWN guest_1 (Unspecified)D N 0UNKNOWN guest_2(Unspecified)D N 0UNKNOWN guest_3(Unspecified) D N 0UNKNOWN guest_4 (Unspecified)D N 0UNKNOWN kitchen_1/kitchen_1192.168.1.6 D N 5060 OK (12 ms) kitchen_2/kitchen_2192.168.1.6 D N 5061 OK (10 ms) office_1 (Unspecified)D N 0UNKNOWN office_2 (Unspecified)D N 0UNKNOWN office_3 (Unspecified) D N 0UNKNOWN sip_proxy 66.232.80.9 5060 Unmonitored sip_proxy-out 66.232.80.9 5060 OK (46 ms) softphone (Unspecified) D N 0UNKNOWN 19 sip peers [Monitored: 9 online, 9 offline Unmonitored: 1 online, 0 offline] pbx*CLI My local softswitch is at the other end of a PON link 1.2km away... The VoIP agent on my iPhone 4 has terrible latency just because I'm on ATT... If I were using an Android on T-mobile that would be around 100ms... The discussion in question is about a scheduler latency, not a network one, though both can be related in the end. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] replace CONFIG_PREEMPT_NONE with CONFIG_PREEMPT
Hello, On Monday 05 September 2011 18:44:39 Michael Büsch wrote: On Mon, 05 Sep 2011 18:11:43 +0200 Felix Fietkau n...@openwrt.org wrote: I am still wondering how enabling preempt could possibly workaround/hide an alignment bug. sounds strange to me. Does somebody have an idea? I didn't look too closely at the function yet, though. Look at BadVA : 6fbb600f - it's not an alignment bug, the address is completely bogus. It just happens to trip on the unhandled unaligned access first because of the lowest bits. This looks like a nasty memory corruption bug, and hiding it with CONFIG_PREEMPT probably eventually makes it show up somewhere else instead. Ok, that makes sense. So instead of enabling preempt, it would be a way better idea to enable various kernel memory debugging options (probably also lockdep) to track this down. It looks like this thread stalled here. Luka, have you been able to run a kernel with lockdep enabled to see what is going one here? -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] motion: bump to 3.2.12
Hello, On Saturday 20 August 2011 16:42:03 Artur Wronowski wrote: Signed-off-by: Artur Wronowski art...@gmail.com Index: multimedia/motion/Makefile === --- multimedia/motion/Makefile(wersja 27915) +++ multimedia/motion/Makefile(kopia robocza) @@ -8,13 +8,13 @@ include $(TOPDIR)/rules.mk PKG_NAME:=motion -PKG_VERSION:=3.2.11.1 +PKG_VERSION:=3.2.12 PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=http://www.lavrsen.dk/sources/motion-daily \ @SF/motion -PKG_MD5SUM:=4e729f129d8f9b9abaed5121c3cd0037 +PKG_MD5SUM:=1ba0065ed50509aaffb171594c689f46 I do not think this builds with recent kernels since it uses include/linux/videodev.h which is the legacy V4L header. Do you know if upstream fixed that? If so, can you resubmit a patch with the up-to-date motion version? Thanks -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Allow for more configurable FFmpeg build options (#7837, #8465)
On Saturday 27 August 2011 23:37:14 Ian Leonard wrote: This patch allows broad control over FFmpeg's libav* build configuration and fixes a typo in ffprobe's install section. The patch resolves #7837 as the choice of building a full libav* is available. This should also resolve #8465 as input devices such as cameras can be enabled. The files created by a full libav* build will be large (several megabytes) and not recommended for end users. Its use could help debugging other issues to learn whether the problem is the openwrt build configuration or another cause. Signed-off-by: Ian Leonard antonla...@gmail.com --- Applied in r28323, thanks! -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] update opennhrp to version 0.12.3
On Sunday 28 August 2011 23:33:04 Artem Makhutov wrote: Hello, this patch updates opennhrp to version 0.12.3 Signed-off-by: Artem Makhutov ar...@makhutov.org Applied in r28324, thanks! -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/5] [packages] motion: update version to fix build with Lunux 2.6.38+
On Monday 29 August 2011 22:09:34 eugene...@gmail.com wrote: From: Eugene San (eugenesan) eugene...@gmail.com Signed-off-by: Eugene San (eugenesan) eugene...@gmail.com --- Applied in r28325, thanks! -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 4/5] [packages] smartmontools: split daemon into separate package
On Monday 29 August 2011 22:09:36 eugene...@gmail.com wrote: From: Eugene San (eugenesan) eugene...@gmail.com Signed-off-by: Eugene San (eugenesan) eugene...@gmail.com --- Applied a slightly different version in r28326, thanks! -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Upgrade mjpeg-streamer
On Wednesday 14 September 2011 14:42:45 Roberto Riggio wrote: This patch upgrades the mjpeg-streamer package to the latest svn revision. It also closes track entry #9896 since the newer version moved to v4l2. Signed-off-by: Roberto Riggio roberto.rig...@create-net.org Applied in r28327, thanks Roberto! -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Update libftdi
On Saturday 10 September 2011 22:21:33 Michael Markstaller wrote: - new upstream release 0.19 - fix missing depend on libusb in initial package, closes #9598 Signed-off-by: Michael Markstaller m...@elabnet.de Applied in r28328, thanks! -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ddns: add provider
On Tuesday 13 September 2011 12:32:49 open...@dnsdynamic.org wrote: Hi, Hope this is the correct way of going about this. I'd like to offer a patch that will allow openwrt users to use dnsdynamic.org as their dynamic dns provider. Thanks Eddie Davis Applied in r28329, thanks! -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [packages] chrony: Upgrade to 1.26
On Sunday 18 September 2011 19:38:23 Michael Heimpold wrote: This patch upgrades chrony to 1.26. Beside several minor bugfixes and improvements, also several vulnerabilities are fixed (compared to 1.23). Signed-off-by: Michael Heimpold m...@heimpold.de --- Applied in r28330, thanks! -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] sslh: Bump to v1.9
On Sunday 25 September 2011 05:44:48 Jonathan McCrohan wrote: This patch bumps the sslh package to v1.9. This update brings about some useful changes, including: * Multiple bind address support * IPv6 support * OpenVPN support * tinc VPN support Tested and working on ar71xx. Signed-off-by: Jonathan McCrohan jmccro...@gmail.com Applied in r28331, thanks! -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] New package: rng-tools for adding entropy from arbitrary source to kernel entropy pool
On Wednesday 21 September 2011 16:50:16 Hannu Nyman wrote: After removal of the network drivers as an entropy source in Linux kernels a while ago, some routers e.g. in ar71xx family experience lack of hardware entropy for /dev/random. The device /dev/random can hang due to that. There are pseudo random numbers available in /dev/urandom, but they do not end up in /dev/random. E.g. tickets #9631 and # are related to this problematics. One tool for adding entropy data from an arbitrary source to the kernel entropy pool is rngd daemon included in the rng-tools package from http://sourceforge.net/projects/gkernel/ Manual page: http://linux.die.net/man/8/rngd The tool can be used to add entropy to the kernel's entropy pool either from some genuine hardware-based entropy source, or as a quickdirty patch also from /dev/urandom. Using urandom isn't a perfect solution, but it will satisfy those applications looking for input from /dev/random. As far as I found out, nobody has complied the rngd daemon package for Openwrt, so far. I made a try out of it, and succeeded both for Backfire and trunk. I defined a package that downloads the sources from SF. (This is my first package definition, so the dependencies and conventions might not be quite correct, but the package seems to compile and work both in Backfire and trunk.) Hopefully somebody can figure out a way to connect some real entropy source in ar71xxx devices through this daemon. The package could be used with real hardware entropy sources (like the Entropy key), if they provide a suitable interface for the daemon to the entropy data from them. Signed-off-by: Hannu Nyman hannu.ny...@iki.fi Applied in r28332, thanks! -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] dnsmasq: update to 2.58
On Thursday 08 September 2011 15:12:50 Raphaël HUCK wrote: Hi, this patch updates dnsmasq to 2.58. The long list of changes is here: http://www.thekelleys.org.uk/dnsmasq/CHANGELOG Applied in r28333, thanks Raphael! -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] add LM95241 kernel module
On Wednesday 10 August 2011 17:07:31 Daniel Golle wrote: This allows building the module for the national lm95241 i2c temperature sensor. Signed-off-by: Daniel Golle dgo...@allnet.de Applied in r28335, thanks Daniel! -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add vlan definitions for SE505v2
On Wednesday 07 September 2011 15:28:44 Manuel Munz wrote: Hi, this patch adds the correct vlan definitions for the Siemens SE505v2. It applies to trunk as well as backfire (please apply here too). On backfire this also patches brcm-2,4, because brcm47xx base-files is just symlinked to brcm-2.4. It also fixes two whitespace issues. Tested with brcm47xx on both trunk and backfire branch and works as expected. Signed-off-by: Manuel Munz freif...@somakoma.de Applied in r28336, thanks! -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/5] [packages] rsync: cosmetic changes after package split
On Friday 30 September 2011 14:37:05 Eugene San wrote: Ok. I just tried to unify style of this file, and wasn't planning tabs-spaces holy-war :-) Although, both approaches can be found all over the code and there is no specific guidelines on subject. Agreed, in general I try to keep this style of 2 spaces for declarations inside define/endef blocks, but having tabs is also valid. Note sure about other editors, but vim for instance does a better highlighting job when using 2 spaces (it's Friday after all). Note, there is at least one change not related to styling: - --disable-acl-support \ + --disable-acl-support On Fri, Sep 30, 2011 at 14:48, Florian Fainelli flor...@openwrt.org wrote: Hello, On Monday 29 August 2011 22:09:35 eugene...@gmail.com wrote: From: Eugene San (eugenesan) eugene...@gmail.com Signed-off-by: Eugene San (eugenesan) eugene...@gmail.com --- net/rsync/Makefile | 26 +- 1 files changed, 13 insertions(+), 13 deletions(-) diff --git a/net/rsync/Makefile b/net/rsync/Makefile index 46670e5..f6d8eb1 100644 --- a/net/rsync/Makefile +++ b/net/rsync/Makefile @@ -21,20 +21,20 @@ PKG_BUILD_PARALLEL:=1 include $(INCLUDE_DIR)/package.mk define Package/rsync - SECTION:=net - CATEGORY:=Network - SUBMENU:=File Transfer - TITLE:=Fast remote file copy program (like rcp) - DEPENDS:=+libpopt - URL:=http://rsync.samba.org/ + SECTION:=net + CATEGORY:=Network + SUBMENU:=File Transfer + TITLE:=Fast remote file copy program (like rcp) + DEPENDS:=+libpopt + URL:=http://rsync.samba.org/ endef define Package/rsyncd - SECTION:=net - CATEGORY:=Network - SUBMENU:=File Transfer - TITLE:=Rsync daemon - DEPENDS:=+rsync + SECTION:=net + CATEGORY:=Network + SUBMENU:=File Transfer + TITLE:=Rsync daemon + DEPENDS:=+rsync endef define Package/rsync/description @@ -54,7 +54,7 @@ CONFIGURE_ARGS += \ --disable-debug \ --disable-locale \ --disable-xattr-support \ - --disable-acl-support \ + --disable-acl-support define Package/rsync/install $(INSTALL_DIR) $(1)/usr/bin @@ -68,7 +68,7 @@ define Package/rsyncd/description endef define Package/rsyncd/conffiles -/etc/rsyncd.conf + /etc/rsyncd.conf endef define Package/rsyncd/install The prefered way of writing a Makefile is how it is right now. Inserting tabs instead of 2 spaces is not what we generally have. -- Florian -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] support for make xconfig
Hello, On Thursday 23 June 2011 10:42:31 Emmanuel Deloget wrote: This patchset brings back the support for the xconfig (and the corresponding kernel_xconfig) top-level targets. Since these targets depends on qt3 (and more precisely the development packages of qt3), some effort has been spent to avoid bringing this huge dependency in OpenWRT. If the build machine has the necessary development packages, then the user will be able to /make [kernel_]xconfig/. Otherwise, a message will be printed when the suer will try to execute these targets. Patch 1/4 to 3/4 in the series are necessary to add support for make xconfig. Patch 4/4 will add support for make kernel_xconfig only if Patch 3/4 has been applied (both patch are modifying the same file, and Patch 4/4 builds upon the tools that are added with Patch 3/4). The patches with svn diff on svn://svn.openwrt.org/openwrt/trunk. I gave this a try, and here is what I get with only the 3 first patches applied: florian@flexo:[~/../trunk]$ make xconfig V=99 make[1]: Entering directory `/home/florian/dev/openwrt/trunk/scripts/config' qconf.cc:26:21: fatal error: qconf.moc: No such file or directory compilation terminated. make[1]: *** [qconf.o] Error 1 make[1]: Leaving directory `/home/florian/dev/openwrt/trunk/scripts/config' make: *** [scripts/config/qconf] Error 2 zsh: exit 2 make xconfig V=99 if I touch scripts/config/qconf.moc, the error is now: make: Entering directory `/home/florian/dev/openwrt/trunk/scripts/config' g++ -I/usr/include/qt3 -DLKC_DIRECT_LINK -c -o qconf.o qconf.cc cc -lqt-mt qconf.o zconf.tab.o kconfig_load.o -o qconf qconf.o: In function `ConfigList::ConfigList(ConfigView*, ConfigMainWindow*, ConfigSettings*)': qconf.cc:(.text+0x15d8): undefined reference to `vtable for ConfigList' qconf.cc:(.text+0x15e4): undefined reference to `vtable for ConfigList' qconf.o: In function `ConfigList::updateSelection()': qconf.cc:(.text+0x1d06): undefined reference to `ConfigList::menuSelected(menu*)' qconf.o: In function `ConfigList::keyPressEvent(QKeyEvent*)': qconf.cc:(.text+0x24dc): undefined reference to `ConfigList::parentSelected()' qconf.cc:(.text+0x257d): undefined reference to `ConfigList::parentSelected()' qconf.cc:(.text+0x2603): undefined reference to `ConfigList::menuSelected(menu*)' qconf.o: In function `ConfigList::contentsMouseReleaseEvent(QMouseEvent*)': qconf.cc:(.text+0x2861): undefined reference to `ConfigList::parentSelected()' qconf.cc:(.text+0x28db): undefined reference to `ConfigList::menuSelected(menu*)' qconf.o: In function `ConfigList::contentsMouseDoubleClickEvent(QMouseEvent*)': qconf.cc:(.text+0x2a12): undefined reference to `ConfigList::parentSelected()' qconf.cc:(.text+0x2a82): undefined reference to `ConfigList::menuSelected(menu*)' qconf.o: In function `ConfigList::focusInEvent(QFocusEvent*)': qconf.cc:(.text+0x2b2c): undefined reference to `ConfigList::gotFocus()' qconf.o: In function `ConfigView::ConfigView(QWidget*, ConfigMainWindow*, ConfigSettings*)': qconf.cc:(.text+0x2b72): undefined reference to `vtable for ConfigView' qconf.cc:(.text+0x2b7e): undefined reference to `vtable for ConfigView' qconf.o: In function `ConfigView::~ConfigView()': qconf.cc:(.text+0x2c7b): undefined reference to `vtable for ConfigView' qconf.cc:(.text+0x2c87): undefined reference to `vtable for ConfigView' qconf.o: In function `ConfigMainWindow::ConfigMainWindow()': qconf.cc:(.text+0x2e0d): undefined reference to `vtable for ConfigMainWindow' qconf.cc:(.text+0x2e1c): undefined reference to `vtable for ConfigMainWindow' qconf.o: In function `ConfigLineEdit::ConfigLineEdit(ConfigView*)': qconf.cc: (.text._ZN14ConfigLineEditC2EP10ConfigView[_ZN14ConfigLineEditC5EP10ConfigView]+0x2f): undefined reference to `vtable for ConfigLineEdit' qconf.cc: (.text._ZN14ConfigLineEditC2EP10ConfigView[_ZN14ConfigLineEditC5EP10ConfigView]+0x3b): undefined reference to `vtable for ConfigLineEdit' collect2: ld returned 1 exit status make: *** [qconf] Error 1 make: Leaving directory `/home/florian/dev/openwrt/trunk/scripts/config' zsh: exit 2 make -C scripts/config qconf Best regards, -- Emmanuel Deloget ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] New package: wt (C++ web toolkit: http://www.webtoolkit.eu/wt )
On Tuesday 06 September 2011 06:44:38 Wade Berrier wrote: Second patch in getting Wt working on openwrt. --- Applied with some minor fixes in r28375, thanks! -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] Fix fcgi++ build, and put it in a separate package
On Tuesday 06 September 2011 06:43:46 Wade Berrier wrote: Hi, The intent of these 2 patches is to get Wt running on openwrt. (It's a c++ web framework). It worked out really well for the application I wrote, although it requires a bit of space when built as shared libraries. (Of course, static builds and aggressive linking can reduce the size for a specific application, but the included makefile will require some modification.) This first patch is to fix a typo when building c++ support for fcgi. It also puts fcgixx in a separate package. The second patch is the bits to build Wt. Wade Applied in r28373, thanks! -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] packages: version bump iproute2 to 2.6.39
On Tuesday 09 August 2011 19:48:31 Daniel Mierswa wrote: Signed-off-by: Daniel Mierswa impu...@impulze.org --- Applied in r28378, thanks! -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] printk() and browser
Hello,
On Tuesday 18 October 2011 06:08:17 abhinav narain wrote:
I am just doing opkg install ath9k_2.6.39.4+..ipk
Do i need to install some other packages on which ath9k driver depends also
Somewhere I read it mught be a symbol table issue.
Any guesses might be useful.
Please help .
Your printk() slows down the entire system and nothing is responsive?
Abhinav
On Mon, Oct 17, 2011 at 8:40 PM, abhinav narain
abhinavnarai...@gmail.comwrote:
I have figure the problem, but I don't know the solution.
Please if someone can tell me about why the following errors are given
on
dmesg.
iptable_raw:Unknow symbol xt_hook_link (err 0)
iptable_raw:Unknow symbol ipt_alloc_initial_table (err 0)
iptable_raw:Unknow symbol xt_hook_unlink (err 0)
xt_NOTRACK: Unknow symbol xt_register_target (err 0)
xtconntrack: Unknown symbol xt_register_match(err0)
xtconntrack: Unknown symbol xt_unregister_match(err0)
There are a lot of such errors on dmesg,
when i compile the following lines of code in at_rx_tasklet() in recv.c
static int ai=0;
if (ai==0) {
printk(abhinav\n); ai++ ;}
I think i have to do some macro unset or something else ?
Can anyone please help...
whoever is trying to patch the kernel
Abhinav
On Mon, Oct 17, 2011 at 6:38 PM, abhinav narain
abhinavnarai...@gmail.com
wrote:
hi,
I am modifying the driver for past few days and noticed something
today.
Though my modifications are seen on the command line, I have one thing
going extremely worn i realized today.
The vanilla installation of the firmware on the router is perfect.
I am able to browse the internet, but when I even do a printk() in the
tasklet function (just once by using a condition),
my laptop is unable to connect to the Internet !
What can be going wrong ?
/etc/resolv.conf is the same for both the cases :
search lan
nameserver 127.0.0.1
Please help.
Abhinav
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] printk() and browser
On Tuesday 18 October 2011 06:26:29 abhinav narain wrote:
As i said, the following errors shoot up on dmesg :
iptable_raw:Unknow symbol xt_hook_link (err 0)
iptable_raw:Unknow symbol ipt_alloc_initial_table (err 0)
iptable_raw:Unknow symbol xt_hook_unlink (err 0)
xt_NOTRACK: Unknow symbol xt_register_target (err 0)
xtconntrack: Unknown symbol xt_register_match(err0)
xtconntrack: Unknown symbol xt_unregister_match(err0)
I don't understand why ?
I do not know either, you did not even describe what you changed.
Abhinav
On Tue, Oct 18, 2011 at 6:25 AM, abhinav narain
abhinavnarai...@gmail.comwrote:
but why is the unknown symbol error ? coming ...
the browser is unable to connect ?
pings are not working ?
how else can I say that the code I modify is working correct ?
Please help
On Tue, Oct 18, 2011 at 6:18 AM, Florian Fainelli
flor...@openwrt.orgwrote:
Hello,
On Tuesday 18 October 2011 06:08:17 abhinav narain wrote:
I am just doing opkg install ath9k_2.6.39.4+..ipk
Do i need to install some other packages on which ath9k driver
depends
also
Somewhere I read it mught be a symbol table issue.
Any guesses might be useful.
Please help .
Your printk() slows down the entire system and nothing is responsive?
Abhinav
On Mon, Oct 17, 2011 at 8:40 PM, abhinav narain
abhinavnarai...@gmail.comwrote:
I have figure the problem, but I don't know the solution.
Please if someone can tell me about why the following errors
are given on
dmesg.
iptable_raw:Unknow symbol xt_hook_link (err 0)
iptable_raw:Unknow symbol ipt_alloc_initial_table (err 0)
iptable_raw:Unknow symbol xt_hook_unlink (err 0)
xt_NOTRACK: Unknow symbol xt_register_target (err 0)
xtconntrack: Unknown symbol xt_register_match(err0)
xtconntrack: Unknown symbol xt_unregister_match(err0)
There are a lot of such errors on dmesg,
when i compile the following lines of code in at_rx_tasklet()
in
recv.c
static int ai=0;
if (ai==0) {
printk(abhinav\n); ai++ ;}
I think i have to do some macro unset or something else ?
Can anyone please help...
whoever is trying to patch the kernel
Abhinav
On Mon, Oct 17, 2011 at 6:38 PM, abhinav narain
abhinavnarai...@gmail.com
wrote:
hi,
I am modifying the driver for past few days and noticed
something
today.
Though my modifications are seen on the command line, I have
one
thing
going extremely worn i realized today.
The vanilla installation of the firmware on the router is
perfect.
I am able to browse the internet, but when I even do a
printk() in
the
tasklet function (just once by using a condition),
my laptop is unable to connect to the Internet !
What can be going wrong ?
/etc/resolv.conf is the same for both the cases :
search lan
nameserver 127.0.0.1
Please help.
Abhinav
--
Florian
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Adding LISP to OpenWrt
Hello Vasileios, On Tuesday 25 October 2011 00:21:11 Vasileios Lakafosis wrote: Dear OpenWrt Developers, this is Vasileios Lakafosis, who, as a member of the Cisco Locator/ID Separation Protocol team http://lisp.cisco.com/ at San Jose, has ported the LISP functionality to OpenWrt. As per the LISP IETF draftshttp://tools.ietf.org/wg/lisp/, the following source code adds basic LISP xTR (Ingress and Egress Tunnel Router) functionality to OpenWrt-enabled routers providing the OpenWrt users with a way to access and try out the LISP Beta Networkhttp://www.lisp4.net/beta-network/ and allowing them to benefit from everything LISP can offer, namely IP portability when changing providers, multi-homing across different providers, simple ingress traffic engineering without BGP and, soon, rapid IPv6 transition. Enabling LISP into OpenWrt requires the addition of essentially three new packages; the user space executable lispd (lisp_0.1-1_ar71xx.ipk) and the loadable kernel modules lisp.ko (kmod-lisp_mod_2.6.32.27+0.1-1_ar71xx.ipk) and lisp_int.ko (kmod-lisp_int_2.6.32.27+0.1-1_ar71xx.ipk). That being said and given that no other pre-existing source code has been modified, you can download the patch file as well as the '.config' (reflecting the package dependency requirements compared to the original .config) from herehttp://dl.dropbox.com/u/1995269/all_lisp_changes.patch.tar.gz . Can you submit the patches to the mailing-list following the guidelines described here: https://dev.openwrt.org/wiki/SubmittingPatches ? this will make the review easier for the package commiters. Thank you. A zipped folder that contains the whole source code of the four packages (the fourth, namely lispconf, being an extra utility to check the lisp map cache) can be downloaded from herehttp://dl.dropbox.com/u/1995269/LISP-OpenWrt-source_packages.tar.gz . Tested on Backfire branch at SVN revision #28461 for target system - Atheros AR71xx and for target profile - WRT160NL (cross-compiled with toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1). The corresponding precompiled LISP (openwrt-lisp-ar71xx-wrt160nl-jffs2-factory.bin) image can be downloaded from herehttp://dl.dropbox.com/u/1995269/openwrt-lisp-ar71xx-wrt160nl-jffs2-fact ory.bin . Please let me know if there is any other information missing that I can provide. Thank you, Vasileios Lakafosis PhD candidate, Georgia Tech -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ipkg-make-index: replace awk calls with stat and cut (from coreutils)
On Thursday 27 October 2011 16:45:11 Raphaël HUCK wrote: Hi all, this patch replaces awk calls with stat and cut, which are both included in coreutils. Have you verified this works on BDS platforms, as well as MacOSX? -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] CONFIG_EXTERNAL_KERNEL_TREE not taken in account
Hi,
Le mardi 29 novembre 2011 17:23:14, Jo-Philipp Wich a écrit :
Hi.
You must pick the target which matches your board, it is used across
various placing, ranging from optimization flag settings to package
architecture fields. The correct one for the LifeBox would be the
brcm63xx target.
Not all Livebox are based on Broadcom BCM63xx, so in that case he would need
to create a new one, e.g: fusiv.
Thomas, you know that you need a toolchain which does not emit any patented
MIPS instructions to work on Lexra/Fusiv CPUs, right?
As far as I can see it in my local test it does indeed build the
external kernel, but applies the version from target/linux/$arch
/Makefile to it.
Example:
$ cat
/home/jow/devel/openwrt/trunk/build_dir/linux-brcm63xx/linux-2.6.39.4/00-R
EADME-FT.txt
To build the linux kernel, extract the archive, and cd
into linux-2.6.15, then run the following commands:
export PATH=/path/to/mips-linux-uclibc/bin:${PATH}
mkdir build-dir
cd build-dir
cp ../.config .
mkdir -p include/linux
cp ../include/linux/autoconf.h include/linux
make -C .. O=$(pwd)
make -C .. O=$(pwd) INSTALL_MOD_PATH=$(pwd)/modules modules_install
mips-linux-uclibc-objcopy -O binary vmlinux vmlinuz
The resulting kernel is the file vmlinuz, to be found in
the directory build-dir. The modules will be found in the
modules/ sub-directory.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Where to place code to reset a watchdog?
Hello Mathias, Le dimanche 04 décembre 2011 18:16:39, Mathias Adam a écrit : Hi, I just got OpenWrt running on a Huawei E970 wireless gateway (in my case, labelled as T-Mobile web'n'walk Box IV). The device has a Broadcom BCM5354 SoC and a built-in 3G USB modem. For reference, it has already been addressed in this open ticket: https://dev.openwrt.org/ticket/2711 However, the device has a hardware watchdog which needs GPIO7 to be toggled regularly. Otherwise, the device simply resets after 2-3 secs, so I wasn't even able to boot into OpenWrt at first. As a quick fix I put together a small kernel patch which adds a timer to regularly perform the GPIO toggle. While this does work for me, I think it could need some cleanup... perhaps, is there already an infrastructure related to platform-/board-specific watchdogs where this could be attached to? Are there other devices already supported by OpenWrt with a similar watchdog? The MTX-1 board (AMD Alchemy) is using a similar GPIO-based watchdog: http://lxr.linux.no/#linux+v3.1.4/drivers/watchdog/mtx-1_wdt.c such a driver could be made generic by the way. (I've also posted to the forum: https://forum.openwrt.org/viewtopic.php?pid=150278#p150278 but didn't get any answers, hope it's better suited here...) Regards, Mathias Adam ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] packages for updated e1000/e1000e driver from SF
Hello, On 12/22/11 10:33, Christoph Thielecke wrote: Hello, here are the packages for updated e1000 and e1000e drivers from sourceforge. Please notice that you can only use one of the drivers kmod-e1000 or e1000 (kmod-e1000e or e1000e). Any particular reasons not to use the mainline e1000 and e1000e drivers? -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] /dev/watchdog from shell script
Hello Bastian, On 12/28/11 11:39, Bastian Bittorf wrote: hi devs, for having a better way not to lost a router i like to use /dev/watchdog from a shell script. the reason is this: Sometimes the oom-killer removes important tasks like ssh + httpd + routing + cron but leaves the watchdog-petting on, so the device is running, but in fact lost. Once started the watchdog daemon does not longer allocate big chunks of memory (if any at all), so this is kind of expected. A better way would be IMHO to use a cron.minutely which fire's an ioctl to /dev/watchdog. if crond is removed, the device should reboot. so i need a way to invoke an ioctl from shellscript. whats the best way, maybe with onboard-tools? I do not think this will work better. If crond is not killed by the OOM killer, then the watchdog keeps being kept alive, and you end up in the same situation. Rather I think we need some kind of software monitoring by a daemon like upstart which makes sures essential software is restarted once killed. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] kexec failure on G300NH
Hello, On 01/05/12 18:36, Peter Naulls wrote: I'm trying to use kexec as a fallback/flash mechanism. But something is going wrong: http://pastebin.com/0uvNnMQd So the device halts after/during the serial port setup, and returns to boot loader. Anyone want to suggest what might be going wrong, or where to start looking? You should enable kernel debugging in your kexec'd kernel and see whether the serial port is being left with IRQs disabled from the original kernel. It may be that the serial port is flooding the kernel with IRQs not handled which in turn causes a reboot. Otherwise, just dump the serial port register contents before leaving the original kernel, and at driver initialization of the kexec'd kernel to see if there are any differences. My 2 cents. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] kexec failure on G300NH
On 01/05/12 23:19, Peter Naulls wrote: On 01/05/2012 09:43 AM, Florian Fainelli wrote: Hello, You should enable kernel debugging in your kexec'd kernel and see whether the serial port is being left with IRQs disabled from the original kernel. I turned on kernel debug, but I'm unsure what exactly I'm looking at. Look for unhandled IRQs which should lead to the message irq N nobody cared if this is the cause of the problem. It may be that the serial port is flooding the kernel with IRQs not handled which in turn causes a reboot. Otherwise, just dump the serial port register contents before leaving the original kernel, and at driver initialization of the kexec'd kernel to see if there are any differences. Sure, but which registers am I looking at - 8250, or something arxx specific? 8250 registers, which are memory-mapped into the CPU address space. I went as far as to set: CONFIG_SERIAL_8250_NR_UARTS=0 CONFIG_SERIAL_8250_RUNTIME_UARTS=0 But this might not be enough by itself. It still reboots at that same point. I also tried disabling early printk. Then this might be an entirely different issue. Try to run the kexec'd kernel uncached and see if that helps (there is a MIPS-specific Kconfig option to do that). -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] kexec failure on G300NH
Le samedi 07 janvier 2012 00:32:31, Peter Naulls a écrit : On 01/06/2012 08:10 AM, Peter Naulls wrote: As an alternative, I'm looking at first jumping to an ar71xx version of u-boot (as per OpenWrt build), all I should need to add to that is flash support for the G300NH(2). Perhaps that puts the system in more consistent state before starting Linux. I was able to make this work. I built the ar71xx u-boot, and was able to add support for the G300NH flash. So, I kexec into u-boot, then am able to reboot back into Linux (loaded from flash). This suggests that u-boot is resetting something that either kexec or the Linux kernel upon boot does not. Anyway, I'll pursue this option right now, but I'm open ideas for fixing kexec directly to new kernel. What about you leaving the watchdog enabled with a timeout sufficiently small that it does not cover the time for loading the kernel to kexec + the time for the kexec'd kernel to start up? -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] kexec failure on G300NH
Le vendredi 06 janvier 2012 20:17:44, Peter Naulls a écrit : On 01/06/2012 02:48 AM, Florian Fainelli wrote: Then this might be an entirely different issue. Try to run the kexec'd kernel uncached and see if that helps (there is a MIPS-specific Kconfig option to do that). CONFIG_MIPS_L1_CACHE_SHIFT=5 ? There's other related stuff in arch/mips/Kconfig but I don't see an explicit disable. No this was a dedicated debugging option to turn on/off running the kernel cached/uncached, but I cannot find it anymore. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] openwrt forum
Hello, On 01/10/12 14:53, foxsam wrote: This is not an openwrt devel question, but is the forum down? For a while I have been having trouble reaching the site from different computers in different locations. I am getting 504 Gateway Time-out errors most of the time. Yes the forum is down for maintenance and will be restarted as soon as possible. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar71xx preemptive kernel
Hello Peter,
On 01/12/12 00:29, Peter Naulls wrote:
For comedy value, I enabled preemption in my G300NH build:
124.49] BUG: scheduling while atomic: swconfig/811/0x0002
[ 124.50] 2 locks held by swconfig/811:
[ 124.50] #0: (genl_mutex){+.+...}, at: [8021cd20] genl_rcv+0x14/0x34
[ 124.51] #1: ((dev-lock)-rlock){+.+...}, at: [801d5e48]
swconfig_get_dev.clone.7+0x7c/0xa0
[ 124.52] Modules linked in: nf_nat_irc nf_conntrack_irc nf_nat_ftp
nf_conntrack_ftp ipt_MASQUERADE iptable_nat nf_nat xt_conntrack xt_CT
xt_NOTRACK iptable_raw xt_state nf_conntrack_ipv4 ne
[ 124.57] Call Trace:
[ 124.58] [80287b68] dump_stack+0x8/0x34
[ 124.58] [8028811c] schedule+0x84/0x50c
[ 124.58] [80288b08] schedule_timeout+0x184/0x1bc
[ 124.59] [800839b0] msleep+0x20/0x30
[ 124.59] [801deec4] rtl8366rb_reset_chip+0x2c/0x90
[ 124.60] [801df1c4] rtl8366rb_sw_reset_switch+0x18/0x74
[ 124.61] [801d6274] swconfig_set_attr+0x1f4/0x23c
[ 124.61] [8021cee8] genl_rcv_msg+0x1a8/0x1f4
[ 124.62] [8021c204] netlink_rcv_skb+0x6c/0xe8
[ 124.62] [8021cd30] genl_rcv+0x24/0x34
[ 124.62] [8021ba5c] netlink_unicast+0x26c/0x350
[ 124.63] [8021bde4] netlink_sendmsg+0x2a4/0x334
[ 124.63] [801e93cc] sock_sendmsg+0x84/0x9c
[ 124.64] [801ebecc] sys_s
The system seemed otherwise ok, but I didn't test beyond this.
Can you describe how you run into this error? Just so that we can
reproduce and fix the problem.
Thanks.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Haveged entropy gathering daemon - Package
Hello, On 01/12/12 12:29, Olipro wrote: Haveged is an entropy gathering daemon which refills the kernel's entropy pool by timing the nanoseconds a CPU takes to complete a loop. The existing haveged only supports a few architectures - I have added support for any given architecture by utilising the CLOCK_MONOTONIC_RAW introduced in kernel 2.6.28 - no doubt this does incur a performance penalty since the architecture specific code uses assembler. unfortunately reading r9 from cp0 on mips requires the cpu to be in kernel or supervisor mode. Unlike rng-tools, using haveged ensure the entropy pool is not simply refilled from /dev/urandom - thus ensuring that evicted entropy is not recycled into the secure pool. however, I'm not entirely sure what dependencies I should be making this rely on to ensure people on say... brcm2.4 don't get it, thus if someone could take a look at it, I'd be most appreciative - the package itself works just fine, I'm using it on my WNDR3800. Though I am not against adding this daemon, rather, I think that we should make some network drivers interrupts fill the kernel entropy pool like it used to be, this should solve the entropy problem on most platforms. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Updated kernel patch in trunk to support brcm47xx BCMA NAND flash
Hello Tathagata,
On 01/10/12 13:00, Tathagata Das wrote:
Hi,
Attached is the updated kernel patch to support brcm47xx BCMA NAND
flash. This patch uses driver/mtd/nand/nand_base.c. I have used latest
trunk source code to create this patch.
I have inlined some comments, how much throughput do you get out of the
driver in read/write?
Regards,
Tathagata tathag...@alumnux.com
9991-bcm47xx-bcma-nandflash.patch
diff -Naur a/arch/mips/bcm47xx/bus.c b/arch/mips/bcm47xx/bus.c
--- a/arch/mips/bcm47xx/bus.c 2011-12-26 13:09:35.028170411 +0530
+++ b/arch/mips/bcm47xx/bus.c 2012-01-05 11:41:55.781832993 +0530
@@ -92,3 +92,46 @@
sflash-numblocks = scc-sflash.numblocks;
sflash-size = scc-sflash.size;
}
+
+#ifdef CONFIG_BCMA_NFLASH
+static int bcm47xx_nflash_bcma_read(struct bcm47xx_nflash *dev, u32 offset,
u32 len, u8 *buf)
+{
+ return bcma_nflash_read(dev-bcc, offset, len, buf);
+}
+
+static int bcm47xx_nflash_bcma_poll(struct bcm47xx_nflash *dev, u32 offset)
+{
+ return bcma_nflash_poll(dev-bcc);
+}
+
+static int bcm47xx_nflash_bcma_write(struct bcm47xx_nflash *dev, u32 offset,
u32 len, const u8 *buf)
+{
+ return bcma_nflash_write(dev-bcc, offset, len, buf);
+}
+
+static int bcm47xx_nflash_bcma_erase(struct bcm47xx_nflash *dev, u32 offset)
+{
+ return bcma_nflash_erase(dev-bcc, offset);
+}
+
+void bcm47xx_nflash_struct_bcma_init(struct bcm47xx_nflash *nflash, struct
bcma_drv_cc *bcc)
+{
+ int i;
+
+ nflash-nflash_type = BCM47XX_BUS_TYPE_BCMA;
+ nflash-bcc = bcc;
+
+ nflash-read = bcm47xx_nflash_bcma_read;
+ nflash-poll = bcm47xx_nflash_bcma_poll;
+ nflash-write = bcm47xx_nflash_bcma_write;
+ nflash-erase = bcm47xx_nflash_bcma_erase;
+
+ nflash-blocksize = bcc-nflash.blocksize;
+ nflash-numblocks = bcc-nflash.numblocks;
+ nflash-pagesize = bcc-nflash.pagesize;
+ nflash-size = bcc-nflash.size;
+
+ for (i=0; i5; i++)
+ nflash-id[i] = bcc-nflash.id[i];
Do you really need to read the flash id that early?
+}
+#endif /* CONFIG_BCMA_NFLASH */
diff -Naur a/arch/mips/bcm47xx/nvram.c b/arch/mips/bcm47xx/nvram.c
--- a/arch/mips/bcm47xx/nvram.c 2011-12-26 13:09:36.274170411 +0530
+++ b/arch/mips/bcm47xx/nvram.c 2012-01-10 14:48:15.981647409 +0530
@@ -21,6 +21,7 @@
#includeasm/mach-bcm47xx/nvram.h
#includeasm/mach-bcm47xx/bcm47xx.h
#includeasm/mach-bcm47xx/bus.h
+#includelinux/mtd/bcm47xx_nand.h
char nvram_buf[NVRAM_SPACE];
EXPORT_SYMBOL(nvram_buf);
@@ -159,6 +160,55 @@
return 0;
}
+static int early_nvram_init_nflash(void)
+{
+ struct nvram_header *header;
+ u32 off;
+ int ret;
+ int len;
+ u32 flash_size = bcm47xx_nflash.size * 1024 * 1024;
+ u8 *tmpbuf = NULL;
+ int i;
+ u32 *src, *dst;
+
+ /* check if the struct is already initilized */
+ if (!flash_size)
+ return -1;
+
+ cfe_env = 0;
+
+ tmpbuf = (u8 *)kmalloc(NFL_SECTOR_SIZE, GFP_KERNEL);
Is not that a little early for using kmalloc? NFL_SECTOR_SIZE is only
512 bytes, so either using a buffer marked with __initdata or allocating
it on the stack should be okay.
+ off = FLASH_MIN;
+ while (off= flash_size) {
+ ret = bcm47xx_nflash.read(bcm47xx_nflash, off,
NFL_SECTOR_SIZE, tmpbuf);
+ if (ret != NFL_SECTOR_SIZE) {
+ goto done;
+ }
+ header = (struct nvram_header *)tmpbuf;
+ if (header-magic == NVRAM_HEADER) {
+ goto found;
+ }
+ off= 1;
+ }
+
+ ret = -1;
+ goto done;
+
+found:
+ len = header-len;
+ header = (struct nvram_header *) KSEG1ADDR(NAND_FLASH1 + off);
+ src = (u32 *) header;
+ dst = (u32 *) nvram_buf;
+ for (i = 0; i sizeof(struct nvram_header); i += 4)
+ *dst++ = *src++;
+ for (; i len i NVRAM_SPACE; i += 4)
+ *dst++ = *src++;
+ ret = 0;
+done:
+ kfree(tmpbuf);
+ return ret;
+}
The identation of these lines is not coherent with the rest.
+
static void early_nvram_init(void)
{
int err = 0;
@@ -185,6 +235,10 @@
err = early_nvram_init_sflash();
if (err 0)
printk(KERN_WARNING can not read from flash:
%i\n, err);
+ } else if (bcm47xx_bus.bcma.bus.drv_cc.flash_type ==
BCMA_NFLASH) {
+ err = early_nvram_init_nflash();
+ if (err 0)
+ printk(KERN_WARNING can not read from nflash:
%i\n, err);
} else {
printk(KERN_WARNING unknow flash type\n);
Consider using a switch() case() statement here, two cases to handle is
enough to start using it.
}
diff -Naur a/arch/mips/bcm47xx/setup.c b/arch/mips/bcm47xx/setup.c
--- a/arch/mips/bcm47xx/setup.c
Re: [OpenWrt-Devel] [PATCH] Haveged entropy gathering daemon - Package
On 01/12/12 16:52, Roman Yeryomin wrote: On 12 January 2012 14:53, Florian Fainelliflor...@openwrt.org wrote: Hello, On 01/12/12 12:29, Olipro wrote: Haveged is an entropy gathering daemon which refills the kernel's entropy pool by timing the nanoseconds a CPU takes to complete a loop. The existing haveged only supports a few architectures - I have added support for any given architecture by utilising the CLOCK_MONOTONIC_RAW introduced in kernel 2.6.28 - no doubt this does incur a performance penalty since the architecture specific code uses assembler. unfortunately reading r9 from cp0 on mips requires the cpu to be in kernel or supervisor mode. Unlike rng-tools, using haveged ensure the entropy pool is not simply refilled from /dev/urandom - thus ensuring that evicted entropy is not recycled into the secure pool. however, I'm not entirely sure what dependencies I should be making this rely on to ensure people on say... brcm2.4 don't get it, thus if someone could take a look at it, I'd be most appreciative - the package itself works just fine, I'm using it on my WNDR3800. Though I am not against adding this daemon, rather, I think that we should make some network drivers interrupts fill the kernel entropy pool like it used to be, this should solve the entropy problem on most platforms. -- If I remember correctly there were some security reasons of removing it from the kernel. Yes, and the reason why you get less interrupts at high rates is because of NAPI which limits the number of interrupts and prefers polling the network adapter for new packets, though I don't think it will be a problem for the SOHO router case routing at most 100Mbits or 1Gbits of trafic in the best case. This should still generate enough interrupts. Although I've done this on ramips platform and didn't face any issues I think that, potentially, a better source or entropy would be radio noise. Of cause if it's possible to get. Indeed, using entropy from Wi-Fi cards would also be a good idea since it's less predictable. As you say, using radio noise would be even better. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Haveged entropy gathering daemon - Package
On 01/12/12 18:43, g@free.fr wrote: - Mail original - De: Roman Yeryominleroi.li...@gmail.com À: OpenWrt Development Listopenwrt-devel@lists.openwrt.org Envoyé: Jeudi 12 Janvier 2012 16:52:36 Objet: Re: [OpenWrt-Devel] [PATCH] Haveged entropy gathering daemon - Package If I remember correctly there were some security reasons of removing it from the kernel. There is 2 reasons: First, network could be sniffed and one could use that knowledge to know what have been added to the entropy pool at which exact time. Very hard to do and much much harder when there is multiple networks as usually you are not able to sniff all networks at the same time. Secondly, dev/random content is supposed to count only first class entropy for crypto purpose, so if you add content that is not of the first class quality, you lie on the size of available entropy. I think the real reason is that mostly programmers are paid to make big server work in a secure way. If a server has only one network card active and that card feed the entropy pool, that would be bad for security if able to sniff that network. So from an audit point of view, it is better to remove an uncertain entropy source. Secondly, big server this day have hardware noise generator to feed the entropy pool. Although I've done this on ramips platform and didn't face any issues I think that, potentially, a better source or entropy would be radio noise. Of cause if it's possible to get. As network traffic from cable, radio noise could be sniffed, on the radio case even without physical access. So that may not be better, maybe even worst. Sure you can sniff noise, but you won't see the same noise as a sniffer than as a receiver using it for entropy anyway due to the nature of the physical medium. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] FTDI additional serial IDs
Hello, On 01/17/12 17:15, Peter Naulls wrote: Add support for the Rainforest Automation Zigbee dongle. This is against 2.6.39 only, however Linux 3.2 does not have this ID either. Signed-of-by: Peter Naulls pe...@chocky.org Please make sure this makes it into next Linux 3.2 stable releases as well. Thanks. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] The problems with getting Cairo to work
Hello Jon, On 01/18/12 03:19, jonsm...@gmail.com wrote: I think I finally found the problem with getting Cairo to work on ARM. What I thought was a problem with an index in the Truetype file actually turned out to be a code generation flaw in the 4.5-linaro compiler. The flaw was in libpixman which is a supporting library for cairo. Compiling libpixman with -O0 made everything work. O1,O2,O3,Os all failed. The flaw was causing random writes that corrupted memory. I identified the subroutine with the code generation problem but I didn't debug the assembly code. While I was working on this bug OpenWRT was updated to the 2012-1 release of 4.6 gcc-linaro. That release fixed the compiler bug that was causing openssl not to build. And guess what, libpixman now works at all optimization levels on that compiler. Thank you for your detailed analysis and letting us know about your progress and findings. If that may interest gcc developpers you might want to report the libxpixman bad code generation to their bugtracker in case they plan on releasing an updated gcc-4.5 release. So I hope my problems are gone for now. I have a dozen test programs and they are all running. I'm hoping the problem is truly fixed and hasn't just moved around again. Once I'm confident with stability I'll prepare patches moving cairo, pixman, freetype, liberation up to more recent versions. Plus I'll package the luaCairo wrapper. With those additions you'll be able to draw pretty pictures on screens with lua scripts. Allright, thanks! -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH V2] ar71xx: support for kernel 3.1
Hello, On 01/18/12 08:47, Dave Taht wrote: On Wed, Jan 18, 2012 at 4:42 AM, Otto Solares Cabreraso...@guug.org wrote: On Thu, Dec 08, 2011 at 11:57:46PM +0100, Hartmut Knaack wrote: juhosg was working quite hard to get us out of sync, with decent support of nbd ;-) It took me a while, but we're finally back on the track. Minimum kernel version is probably still 3.1.1. Successfully tested with kernel 3.1.4 on a WR1043ND. Kernel version in the Makefile still needs to be adjusted manually. Any comments appreciated. Enjoy. Hi Harmut, do you have something for 3.2? I don't want to duplicate efforts :=) Personally I feel that skipping 3.2 entirely and going to 3.3 is the right course, as that has byte queue limits, a fixed implementation of RED, aRED, multiple improvements to SFQ that make it scale up much better, and behave better in the general case, and a new combination of SFQ and RED that looks very promising. Well sure these are interesting features to pull from an updated kernel version, but it is not a reason for skipping 3.2 entirely, especially if we feel like making this the base kernel version for releasing Attitude Adjustement at some point. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt-Hackers] brcm63xx new boards support
Hello, On Sunday 22 January 2012 13:19:28 Álvaro Fernández Rojas wrote: Hi guys, There are some open tickets that contain patches which add support for new brcm63xx boards. These tickets are #10732 https://dev.openwrt.org/ticket/10732 and #10764 https://dev.openwrt.org/ticket/10764. In #10732 https://dev.openwrt.org/ticket/10732 you only need to replace the files that I provide. In this files I have also patched the number of buttons as suggested in #10717 https://dev.openwrt.org/ticket/10717. Once support has been added for this board, I can make the same set of patches for #10764 https://dev.openwrt.org/ticket/10764. Please submit the final patch to openwrt-devel following the documentation here: https://dev.openwrt.org/wiki/SubmittingPatches Greetings and thanks for your time ;). -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] brcm63xx 96348A-122 board support (Comtrend 5365)
On Sunday 22 January 2012 14:45:45 Álvaro Fernández Rojas wrote:
This adds support for Comtrend 5365. Open commits are
https://dev.openwrt.org/ticket/10732 and
https://dev.openwrt.org/ticket/10717. Also modifies increases the number
of buttons supported by brcm63xx boards. Directory to apply patch is:
target/linux/brcm63xx
Signed-off-by: Álvaro Fernández Rojas nolt...@gmail.com
Looks good, except that you missed updating the 3.0, 3.1 and 3.2 patches, can
you resubmit with these patches updated as well?
Thanks.
Index: patches-2.6.39/200-extended-platform-devices.patch
===
--- patches-2.6.39/200-extended-platform-devices.patch(revisión:
29846)
+++ patches-2.6.39/200-extended-platform-devices.patch(copia de
trabajo)
@@ -15,7 +15,7 @@
@@ -61,6 +61,10 @@ struct board_info {
/* Buttons */
- struct gpio_button buttons[2];
+ struct gpio_button buttons[4];
+
+/* Additional platform devices */
+struct platform_device **devs;
Index: patches-2.6.39/457-board_96348A-122.patch
===
--- patches-2.6.39/457-board_96348A-122.patch (revisión: 0)
+++ patches-2.6.39/457-board_96348A-122.patch (revisión: 0)
@@ -0,0 +1,78 @@
+--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
b/arch/mips/bcm63xx/boards/board_bcm963xx.c
+@@ -1009,6 +1009,67 @@
+ },
+ };
+
++static struct board_info __initdata board_96348A_122 = {
++.name = 96348A-122,
++.expected_cpu_id= 0x6348,
++
++.has_uart0 = 1,
++.has_enet1 = 1,
++.has_pci= 1,
++
++.enet1 = {
++.force_speed_100= 1,
++.force_duplex_full = 1,
++},
++
++.has_ohci0 = 1,
++
++.leds = {
++{
++.name = power,
++.gpio = 0,
++.active_low = 1,
++.default_trigger = default-on,
++},
++{
++.name = alarm,
++.gpio = 2,
++.active_low = 1,
++},
++{
++.name = wps,
++.gpio = 6,
++.active_low = 1,
++},
++},
++.buttons = {
++{
++.desc = reset,
++.gpio = 33,
++.active_low = 1,
++.type = EV_KEY,
++.code = KEY_RESTART,
++.threshold = 3,
++},
++{
++.desc = wifi,
++.gpio = 34,
++.active_low = 1,
++.type = EV_KEY,
++.code = BTN_0,
++.threshold = 3,
++},
++{
++.desc = wps,
++.gpio = 35,
++.active_low = 1,
++.type = EV_KEY,
++.code = KEY_WPS_BUTTON,
++.threshold = 3,
++},
++},
++};
++
+ #endif
+
+ /*
+@@ -2068,6 +2129,7 @@
+ board_V2500V_BB,
+ board_V2110,
+ board_ct536_ct5621,
++board_96348A_122,
+ #endif
+
+ #ifdef CONFIG_BCM63XX_CPU_6358
\ No newline at end of file
Cambios de propiedades en patches-2.6.39/457-board_96348A-122.patch
___
Añadido: svn:executable
+ *
Index: patches-2.6.39/500-ssb-add-callback-for-sprom.patch
===
--- patches-2.6.39/500-ssb-add-callback-for-sprom.patch (revisión:
29846)
+++ patches-2.6.39/500-ssb-add-callback-for-sprom.patch (copia de
trabajo)
@@ -1,6 +1,6 @@
--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
+++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
-@@ -2128,6 +2128,17 @@ static struct ssb_sprom bcm63xx_sprom =
+@@ -2190,6 +2190,17 @@ static struct ssb_sprom bcm63xx_sprom =
.boardflags_lo = 0x2848,
.boardflags_hi = 0x,
};
@@ -18,7 +18,7 @@
#endif
/*
-@@ -2397,8 +2408,9 @@ int __init board_register_devices(void)
+@@ -2459,8 +2470,9 @@ int __init board_register_devices(void)
if (!board_get_mac_address(bcm63xx_sprom.il0mac)) {
memcpy(bcm63xx_sprom.et0mac, bcm63xx_sprom.il0mac, ETH_ALEN);
memcpy(bcm63xx_sprom.et1mac, bcm63xx_sprom.il0mac, ETH_ALEN);
Index: patches-2.6.39/100-reset_buttons.patch
Re: [OpenWrt-Devel] brcm63xx 96348A-122 board support (Comtrend 5365)
On Sunday 22 January 2012 14:45:45 Álvaro Fernández Rojas wrote:
This adds support for Comtrend 5365. Open commits are
https://dev.openwrt.org/ticket/10732 and
https://dev.openwrt.org/ticket/10717. Also modifies increases the number
of buttons supported by brcm63xx boards. Directory to apply patch is:
target/linux/brcm63xx
Signed-off-by: Álvaro Fernández Rojas nolt...@gmail.com
I spoke too soon, nevermind :)
Index: patches-2.6.39/200-extended-platform-devices.patch
===
--- patches-2.6.39/200-extended-platform-devices.patch(revisión:
29846)
+++ patches-2.6.39/200-extended-platform-devices.patch(copia de
trabajo)
@@ -15,7 +15,7 @@
@@ -61,6 +61,10 @@ struct board_info {
/* Buttons */
- struct gpio_button buttons[2];
+ struct gpio_button buttons[4];
+
+/* Additional platform devices */
+struct platform_device **devs;
Index: patches-2.6.39/457-board_96348A-122.patch
===
--- patches-2.6.39/457-board_96348A-122.patch (revisión: 0)
+++ patches-2.6.39/457-board_96348A-122.patch (revisión: 0)
@@ -0,0 +1,78 @@
+--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
b/arch/mips/bcm63xx/boards/board_bcm963xx.c
+@@ -1009,6 +1009,67 @@
+ },
+ };
+
++static struct board_info __initdata board_96348A_122 = {
++.name = 96348A-122,
++.expected_cpu_id= 0x6348,
++
++.has_uart0 = 1,
++.has_enet1 = 1,
++.has_pci= 1,
++
++.enet1 = {
++.force_speed_100= 1,
++.force_duplex_full = 1,
++},
++
++.has_ohci0 = 1,
++
++.leds = {
++{
++.name = power,
++.gpio = 0,
++.active_low = 1,
++.default_trigger = default-on,
++},
++{
++.name = alarm,
++.gpio = 2,
++.active_low = 1,
++},
++{
++.name = wps,
++.gpio = 6,
++.active_low = 1,
++},
++},
++.buttons = {
++{
++.desc = reset,
++.gpio = 33,
++.active_low = 1,
++.type = EV_KEY,
++.code = KEY_RESTART,
++.threshold = 3,
++},
++{
++.desc = wifi,
++.gpio = 34,
++.active_low = 1,
++.type = EV_KEY,
++.code = BTN_0,
++.threshold = 3,
++},
++{
++.desc = wps,
++.gpio = 35,
++.active_low = 1,
++.type = EV_KEY,
++.code = KEY_WPS_BUTTON,
++.threshold = 3,
++},
++},
++};
++
+ #endif
+
+ /*
+@@ -2068,6 +2129,7 @@
+ board_V2500V_BB,
+ board_V2110,
+ board_ct536_ct5621,
++board_96348A_122,
+ #endif
+
+ #ifdef CONFIG_BCM63XX_CPU_6358
\ No newline at end of file
Cambios de propiedades en patches-2.6.39/457-board_96348A-122.patch
___
Añadido: svn:executable
+ *
Index: patches-2.6.39/500-ssb-add-callback-for-sprom.patch
===
--- patches-2.6.39/500-ssb-add-callback-for-sprom.patch (revisión:
29846)
+++ patches-2.6.39/500-ssb-add-callback-for-sprom.patch (copia de
trabajo)
@@ -1,6 +1,6 @@
--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
+++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
-@@ -2128,6 +2128,17 @@ static struct ssb_sprom bcm63xx_sprom =
+@@ -2190,6 +2190,17 @@ static struct ssb_sprom bcm63xx_sprom =
.boardflags_lo = 0x2848,
.boardflags_hi = 0x,
};
@@ -18,7 +18,7 @@
#endif
/*
-@@ -2397,8 +2408,9 @@ int __init board_register_devices(void)
+@@ -2459,8 +2470,9 @@ int __init board_register_devices(void)
if (!board_get_mac_address(bcm63xx_sprom.il0mac)) {
memcpy(bcm63xx_sprom.et0mac, bcm63xx_sprom.il0mac, ETH_ALEN);
memcpy(bcm63xx_sprom.et1mac, bcm63xx_sprom.il0mac, ETH_ALEN);
Index: patches-2.6.39/100-reset_buttons.patch
===
--- patches-2.6.39/100-reset_buttons.patch(revisión: 29846)
+++
Re: [OpenWrt-Devel] DSL support and luci integration
Hello, On 01/23/12 02:34, Philip Prindeville wrote: On 1/21/12 1:18 AM, Lee Essen wrote: On 20 Jan 2012, at 23:47, Philip Prindeville wrote: I'd sure like to see netlink being used to communicate speed/carrier changes up into userspace. Unfortunately there's absolutely no netlink support in the lantiq driver and I don't think any of that info is available elsewhere, I would have thought trying to add a netlink capability would be a bit extreme? (and probably well outside my capability) … and that would then need to be done for every subsequent DSL driver to maintain standardisation. There is an ioctl interface, which also works without the daemon running, which I did consider, but my thought was that this would require an extra binary to maintain (unless there's a simple lua ioctl interface, but I couldn't find one) and would have a lot less transparency than a script -- but I'm happy to knock something up to make use of this if it's considered a better approach. Regards, Lee. There aren't that many DSL flavors out there... Danube, Solos, Viking... that's probably 90% of the market I'm guessing. You missed all the BCM63xx SoCs, which represent 90% of the DSL market actually, though their drivers are not opensource which is why people tend to forget about them. Once it gets done for one architecture, I'm sure someone on the linux-atm mailing list would port it to others. I might do it for the Solos if I have a working example of the netlink portion, then I can figure out how to interrogate the hardware for link quality changes. Having a generic DSL stack in Linux will be quite some work from an acceptance perspective because: - there are not only DSL ATM drivers in Linux (e.g: SoNET), and they need to be supported too by this stack - there is only one modern DSL/ATM driver right now which is solos, I am not sure Lantiq has any plans for mainlining their driver, rewriting ar7-atm to fit into that model is also a lot of work Anyway, if you got that way, I think you could use generic netlink in order to avoid the complexity of netlink and still have something useful. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Let's fix the OpenWrt patch acceptance problem!
Hello, On Tuesday 24 January 2012 21:14:23 Michael Heimpold wrote: Hi, In my opinion, the main issue is not that we don't give out SVN access fast enough, from my personal experience I can say that I got SVN access very quickly after I offered taking over maintainership for php5 package. After some months I suggested to split php into multiple packages (for pecl modules) but I did not yet get svn acccess for this. Not even a response to my requests. it's that people consider SVN access necessary for contributing in the first place. I don't think so. I'm fine with submitting patches to the list. To speed up my personal workflow I placed 'packages' on github so that I can send pull requests to the list (git://github.com/mhei/openwrt-packages.git) in the near future (but I'm still novice with git - learning by doing :-) Sending pull-requests along with the patches contained in the pull request sounds good to me. FYI, buildroot proceeds like this. And yes, please stay hard giving commit access away to keep the quality on the current high level. And yes, tell me/flame me when I commit rubbish or send patches which doesn't apply/are broken... So to summarize: for me the main trouble is not how the workflow is - I'll try to adapt myself - but I need feedback on the list as I've only little time on IRC... willing to organize and take care of maintaining the tree and compile testing and reviewing the incoming changes? Is there already work done/docs about setting up buildbot slaves/ cronjobs for nightly builds... ? I feel that my CPU could do something useful when I'm sleeping/at work :-) You might want to contact Jo and Travis about this since they both administer such a buildbot. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Let's fix the OpenWrt patch acceptance problem!
On Tuesday 24 January 2012 15:59:18 Emmanuel Deloget wrote: Le 01/24/2012 02:06 PM, Jonathan McCrohan a écrit : On 24/01/12 08:22, Dave Taht wrote: My principal critique of this workflow is that I tend to view svn as part of the problem to a large extent. If I do a patch in my own (git) tree to test with, I invariably have to rebase that tree when it comes down from svn. as I am frequently offline, not being able to do a 'svn log' is the second deal-killer for me, for svn usage. I also see svn as part of the problem. I think a move towards the linux-kernel development model would be a great benefit. Using git would allow users to make many small fixes in their own tree and send single a pull request for fixes to x,y and z to a member of the patch review team for ACK or NAK who can then commit to master. Hopefully this will result in fewer stray patches. The original user will then show up in git blame and will make tracing errors far easier. Currently, unless you have commit rights, everything comes from one of the few core developers and you have to manually look up the changeset to figure out who is responsible for it. I would also give my vote to git, as this solution proved to be far more scalable than svn. Since importing an svn tree to git is quite easy, and since trac proposed a git connector, such a move should be nearly painless (unless you have the full openwrt svn as an svn:external in your own tree). Let's just keep focused on the proposal here and not the use of a different tool for the main repository. SVN is scalable as well, what is not is giving access to the main repository right now. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Low level boot on MIPS CPUs
On Monday 06 February 2012 18:00:17 Peter Naulls wrote: On 02/06/2012 08:52 AM, jonsm...@gmail.com wrote: Most ARM CPUs have boot ROMs for getting the initial image out of flash. I'm referring to the boot loader that loads uboot, not uboot. The ARM CPUs I've worked with search for a signature in flash, if they can't find a valid signature they load from UART instead. Or you can use a jumper to force loading from UART. This allows you to recover from being bricked or initially load the flash without needing a special programmer. Do the MIPS based router CPUs have this ability? What does the on MIPS CPU ROM do if the image in flash is invalid? MIPS systems varies as much as ARM ones do. The short answer, is it depends upon the hardware. For systems which lack serial/ROM level recovery, you'll need to use JTAG. Some systems I work with lack even that. Actually, I have never seen a single MIPS system out there having such a boot ROM capability. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Low level boot on MIPS CPUs
On Monday 06 February 2012 19:20:21 jonsm...@gmail.com wrote: On Mon, Feb 6, 2012 at 1:08 PM, Florian Fainelli flor...@openwrt.org wrote: On Monday 06 February 2012 18:00:17 Peter Naulls wrote: On 02/06/2012 08:52 AM, jonsm...@gmail.com wrote: Most ARM CPUs have boot ROMs for getting the initial image out of flash. I'm referring to the boot loader that loads uboot, not uboot. The ARM CPUs I've worked with search for a signature in flash, if they can't find a valid signature they load from UART instead. Or you can use a jumper to force loading from UART. This allows you to recover from being bricked or initially load the flash without needing a special programmer. Do the MIPS based router CPUs have this ability? What does the on MIPS CPU ROM do if the image in flash is invalid? MIPS systems varies as much as ARM ones do. The short answer, is it depends upon the hardware. For systems which lack serial/ROM level recovery, you'll need to use JTAG. Some systems I work with lack even that. Actually, I have never seen a single MIPS system out there having such a boot ROM capability. It is a very useful ability. You can solder the flash chips on empty and then use the UART to program them during test. UART first loads a little program to tiny on-CPU-chip SRAM. This program in turns knows how to program the flash chip and then reads the full image from UART with error detection. You need the SRAM because the DRAM controller is not set up yet. u-boot support this, check out CONFIG_SPL. Takes about 30 seconds and no special equipment to initially program our ARM boards. Same procedure can unbrick them. Yeah, I have used that on a custom AT91 board, it definitively is useful, but MIPS integrators did not feel the need to get this standardized or even brought to customers, so, if you want a similar feature, you'd have to use a custom bootloader and protect the region of the flash where this rescue bootloader is. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Expected RT2880-F based AP performance?
Hello, While I was porting the ramips target to a Ralink evaluation board (V11ST-FE) using a RT2880-F SoC, I noticed that I was not getting more than 26Mbits/sec TCP traffic using iperf. The station was connected with N-rates, and I was running a trunk from yesterday. My nearby radio environment is not so crowded, and changing the channel to something more busy showed even worse performance (down to 5Mbits/sec in some cases). Is this something you also observed on your RT2880-F based APs? Thanks. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Expected RT2880-F based AP performance?
Hello Helmut, On 02/13/12 12:31, Helmut Schaa wrote: On Mon, Feb 13, 2012 at 10:33 AM, Florian Fainelliflor...@openwrt.org wrote: While I was porting the ramips target to a Ralink evaluation board (V11ST-FE) using a RT2880-F SoC, I noticed that I was not getting more than 26Mbits/sec TCP traffic using iperf. The station was connected with N-rates, and I was running a trunk from yesterday. My nearby radio environment is not so crowded, and changing the channel to something more busy showed even worse performance (down to 5Mbits/sec in some cases). Is this something you also observed on your RT2880-F based APs? rt2x00 throughput is in general seeing performance impacts when the channel is not entirely clear. I've no idea yet why but the impact looks much worse then with other drivers (like ath9k). Do you think we should move this discussion to linux-wireless in the hope that someone there might help? I am definitively willing to test patches since I don't think we are hitting a CPU limitation there. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] package/kexec-tools: fix build with gcc 4.6.x
Hello, On 01/07/12 03:54, Arnaud Lacombe wrote: Hi, On Mon, Dec 12, 2011 at 11:25 AM, Arnaud Lacombelacom...@gmail.com wrote: This fixes the following build error: make[4]: Entering directory `target-i386_gcc-4.6.1_binutils_2.21.1_uClibc-0.9.32/kexec-tools-2.0.2' mkdir -p purgatory i486-openwrt-linux-uclibc-gcc --no-undefined -nostartfiles -nostdlib -nodefaultlibs -e purgatory_start -r -o purgatory/purgatory.ro \ purgatory/purgatory.o purgatory/printf.o purgatory/string.o \ purgatory/arch/i386/entry32-16.o purgatory/arch/i386/entry32-16-debug.o \ purgatory/arch/i386/entry32.o purgatory/arch/i386/setup-x86.o \ purgatory/arch/i386/stack.o purgatory/arch/i386/compat_x86_64.o \ purgatory/arch/i386/purgatory-x86.o purgatory/arch/i386/console-x86.o \ purgatory/arch/i386/vga.o purgatory/arch/i386/pic.o \ purgatory/arch/i386/crashdump_backup.o purgatory/sha256.o \ i486-openwrt-linux-uclibc-gcc: error: unrecognized option '--no-undefined' Original oatch from `kexec-tools' repository: commit 8880e5b8a295788dcae8f5cc038de92cd97b6807 Author: Simon Hormanho...@verge.net.au Date: Wed Mar 30 08:34:39 2011 +0900 build: Pass --no-undefined as a linker option gcc-4.6 does not accept --no-undefined as a compiler option Reported-by: Civilcivil.o...@gmail.com Acked-by: Eric W. Biedermanebied...@xmission.com Signed-off-by: Simon Hormanho...@verge.net.au Signed-off-by: Arnaud Lacombelacom...@gmail.com ping ? Fixed with r30493 -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] cc1: all warnings being treated as errors
Hello, Le lundi 13 février 2012 21:04:53, Nerijus Baliunas a écrit : Hello, I've updated from svn trunk and udpxy package no longer compiles: mipsel-openwrt-linux-uclibc-gcc -Os -pipe -mips32r2 -mtune=mips32r2 -fno-caller-saves -fhonour-copts -msoft-float -I/a/openwrt/kamikaze/staging_dir/target-mipsel_r2_uClibc-0.9.33/usr/inclu de -I/a/openwrt/kamikaze/staging_dir/target-mipsel_r2_uClibc-0.9.33/include -I/a/openwrt/kamikaze/staging_dir/toolchain-mipsel_r2_gcc-4.6-linaro_uClib c-0.9.33/usr/include -I/a/openwrt/kamikaze/staging_dir/toolchain-mipsel_r2_gcc-4.6-linaro_uClib c-0.9.33/include -W -Wall -Werror --pedantic -W -Wall -Werror --pedantic -DUDPXREC_MOD -DNDEBUG -DTRACE_MODULE -c udpxy.c -o udpxy.o udpxy.c: In function 'accept_requests': udpxy.c:914:25: error: variable 'rc' set but not used [-Werror=unused-but-set-variable] cc1: all warnings being treated as errors Was this change (all warnings being treated as errors) intentional? Yes, updating the toolchain to gcc-4.6 implies that more warnings are turned on by default by the compiler. Do we expect all packages to have no warnings? Yes, or either selectively build with Wno-error to disable warnings as errors. Usually these warnings are caused by genuine bugs or unused variables/functions, so fixing them are beneficial in any case. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] using systemtap
Hello, Le 02/20/12 22:53, abhinav narain a écrit : hi, I can't find package for systemtap for OpenWrt, is it available ? I looked at trunk and Kamikaze but were not present in packages folder. I am working on a copy of trunk (~august build), currently. I couldn't find any docs related to it, any comments ? We have no systemtap package, however you should be able to build the Linux perf utility which proposes equivalent functions. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] sysupgrade: try harder during an error
Hi, Le 02/25/12 17:56, Jo-Philipp Wich a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. I think it should be handled in mtd, rewriting the complete image only because a single block had a transient erase problem is a bit excessive imo. It also means that sysupgrade would loop forever in case of a really fatal issue, like when the image is too large for the given mtd partition. I'd say the mtd util should perform 3-5 consecutive tries in case of a block erase problem and then finally exit with a non zero code to notify the caller about the problem. If you are getting an erase block failure, I see only 3 valid root causes for this: - block is genuinly dead, then you can't do much about it but skip it, but your device has then serious issues, and retries don't help - your Flash controller/driver is not robust enough and reports erase block failures while it should not, retries workaround the issue - your system is running out of memory for processing the erase ioctl() then you also need to workaround this issue. The exit code could convey the nature of the problem, e.g. erase issue or mtd too short; this would allow sysupgrade to take appropriate actions without brute-forcing the flash into death. If you are really running out of valid erase blocks, then I would suggest moving to a more robust flash-filesystem such as UBI, at the expense of loosing some free space obviously. ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9JErwACgkQdputYINPTPNlFgCeNaKCXiYIC+jxf2WhGxl7vAG8 988AnAzsUbpU14L5cXIBa3ESqSt3ymns =ouxM -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] wifi detect returns nothing (openwrt trunk with RB411 R52 (lspci lists radio as AR5413 802.11abg)
Hello, Le 02/28/12 02:55, Brian Hutchinson a écrit : On Mon, Feb 27, 2012 at 5:04 PM, Russell Senior russ...@personaltelco.net wrote: I build from trunk. I selected (=y) it from menuconfig under kernel and wireless. You can search in menuconfig with '/'. Ah, I have a /etc/config/wireless file now and the radio is finally doing something! Thanks guys for pointing me in the right direction. I compiled in ath5k support. Does mac80211 support any kind of 802.11a turbo mode (11ast)? I had really hoped that I could use channel 160 but reading up on the feature it looks like only madwifi does 11ast??? No this is not supported because this used to be implemented as a driver private wireless extension. mac80211 only handles standard rates. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ECDSA support in openssh and openssl
Hello,
Le 02/28/12 07:29, Ondrej Famera a écrit :
This enables support for ECDSA keys in openssl and since it is supported
in openSSH since version 5.7 ECDSA keys can be then used by
openssh-{server,keygen,client} and are automaticaly generated on sshd
start.
- tested to be working on routerstation PRO with trunk r30744
I am not against it, but what's the size impact on openssl with the
enabling of ecdsa? and cannot it be turned on as an openssl
configuration option instead? (such that packages dans depend on this or
select this option).
Signed-off-by: Ondrej Faměra fam...@fi.muni.cz
---
Index: package/openssl/Makefile
===
--- package/openssl/Makefile (revision 30744)
+++ package/openssl/Makefile (working copy)
@@ -74,7 +74,7 @@
OPENSSL_NO_CIPHERS:= no-idea no-md2 no-mdc2 no-rc5 no-sha0 no-smime \
no-rmd160 no-aes192 no-ripemd no-camellia no-ans1 no-krb5
-OPENSSL_OPTIONS:= shared no-ec no-err no-hw no-threads zlib-dynamic
no-sse2
+OPENSSL_OPTIONS:= shared no-err no-hw no-threads zlib-dynamic no-sse2
ifdef CONFIG_OPENSSL_ENGINE
OPENSSL_OPTIONS += -DHAVE_CRYPTODEV
Index: packages/net/openssh/files/sshd.init
===
--- packages/net/openssh/files/sshd.init (revision 30744)
+++ packages/net/openssh/files/sshd.init (working copy)
@@ -7,7 +7,7 @@
SERVICE_USE_PID=1
start() {
- for type in rsa dsa; do {
+ for type in rsa dsa ecdsa; do {
# check for keys
key=/etc/ssh/ssh_host_${type}_key
[ ! -f $key ] {
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Updated kernel patch in trunk to support brcm47xx BCMA NAND flash
Hello Tatha,
Le 02/28/12 07:50, Tathagata Das a écrit :
Hi,
Attached is the updated kernel patch to support brcm47xx BCMA NAND flash.
I have used latest trunk source code to create this patch. I have tested it on
Netgear WNR3500Lv2.
Thanks to Florian and Hauke for their comments.
And thank you for your efforts on this, I am sorry, but I found a couple
of small issues in your patch, which I attached inline for easier
commenting:
9991-bcm47xx-bcma-nandflash.patch
diff -Naur a/arch/mips/bcm47xx/bus.c b/arch/mips/bcm47xx/bus.c
--- a/arch/mips/bcm47xx/bus.c 2012-02-17 16:34:21.0 +0530
+++ b/arch/mips/bcm47xx/bus.c 2012-02-23 18:22:17.0 +0530
@@ -2,6 +2,7 @@
* BCM947xx nvram variable access
*
* Copyright (C) 2011 Hauke Mehrtensha...@hauke-m.de
+ * Copyright (C) 2011-2012 Tathagata Dastathag...@alumnux.com
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -92,3 +93,9 @@
sflash-numblocks = scc-sflash.numblocks;
sflash-size = scc-sflash.size;
}
+
+void bcm47xx_nflash_struct_bcma_init(struct bcm47xx_nflash *nflash, struct
bcma_drv_cc *bcc)
+{
+ nflash-nflash_type = BCM47XX_BUS_TYPE_BCMA;
+ nflash-bcc = bcc;
+}
diff -Naur a/arch/mips/bcm47xx/nvram.c b/arch/mips/bcm47xx/nvram.c
--- a/arch/mips/bcm47xx/nvram.c 2012-02-17 16:34:22.0 +0530
+++ b/arch/mips/bcm47xx/nvram.c 2012-02-23 18:20:57.0 +0530
@@ -4,6 +4,7 @@
* Copyright (C) 2005 Broadcom Corporation
* Copyright (C) 2006 Felix Fietkaun...@openwrt.org
* Copyright (C) 2010-2011 Hauke Mehrtensha...@hauke-m.de
+ * Copyright (C) 2011-2012 Tathagata Dastathag...@alumnux.com
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -21,6 +22,7 @@
#includeasm/mach-bcm47xx/nvram.h
#includeasm/mach-bcm47xx/bcm47xx.h
#includeasm/mach-bcm47xx/bus.h
+#includelinux/mtd/bcm47xx_nand.h
char nvram_buf[NVRAM_SPACE];
EXPORT_SYMBOL(nvram_buf);
@@ -159,6 +161,53 @@
return 0;
}
+static int early_nvram_init_nflash(void)
+{
+ struct nvram_header *header;
+ u32 off;
+ int ret;
+ int len;
+ u32 flash_size = bcm47xx_nflash.size;
+ u8 tmpbuf[NFL_SECTOR_SIZE];
+ int i;
+ u32 *src, *dst;
+
+ /* check if the struct is already initilized */
+ if (!flash_size)
+ return -1;
+
+ cfe_env = 0;
+
+ off = FLASH_MIN;
+ while (off= flash_size) {
+ ret = bcma_nflash_read(bcm47xx_nflash.bcc, off,
NFL_SECTOR_SIZE, tmpbuf);
+ if (ret != NFL_SECTOR_SIZE) {
+ goto done;
+ }
The brackets here are not required.
+ header = (struct nvram_header *)tmpbuf;
+ if (header-magic == NVRAM_HEADER) {
+ goto found;
+ }
They are not required here too.
+ off= 1;
+ }
+
+ ret = -1;
+ goto done;
+
+found:
+ len = header-len;
+ header = (struct nvram_header *) KSEG1ADDR(NAND_FLASH1 + off);
+ src = (u32 *) header;
+ dst = (u32 *) nvram_buf;
+ for (i = 0; i sizeof(struct nvram_header); i += 4)
+ *dst++ = *src++;
+ for (; i len i NVRAM_SPACE; i += 4)
+ *dst++ = *src++;
Did you have to do this because memcpy() did not work, due to byte access
instead of word access?
+ ret = 0;
+done:
+ return ret;
+}
+
[snip]
+
+/* Issue a nand flash command */
+static inline void bcma_nflash_cmd(struct bcma_drv_cc *cc, u32 opcode)
+{
+ bcma_cc_write32(cc, NAND_CMD_START, opcode);
+ bcma_cc_read32(cc, NAND_CMD_START);
+}
+
+/* Check offset and length */
+static int bcma_nflash_offset_is_valid(struct bcma_drv_cc *cc, u32 offset, u32
len, u32 mask)
+{
+ if ((offset mask) != 0 || (len mask) != 0) {
+ pr_err(%s(): Address is not aligned. offset: %x, len: %x, mask:
%x\n, __func__, offset, len, mask);
+ BUG_ON(1);
+ return 1;
+ }
a BUG_ON() here is a little hard, just the printk should be sufficient in case
someone is doing unaligned accesses.
+
+ if offset + len) 20) cc-nflash.size) ||
+ offset + len) 20) == cc-nflash.size)
these two lines are equal to:
((offset + len) 20)= cc-nflash.size
+ (((offset + len) ((1 20) - 1)) != 0))) {
+ pr_err(%s(): Address is outside Flash memory region. offset: %x,
len: %x, mask: %x\n, __func__, offset, len, mask);
+ return 1;
+ }
+
+ return 0;
+}
Everything else is fine from my perspective otherwise.
Thank you.
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] OpenWrt at CCC Camp
Hi devs, Some of us will be at the CCC Camp this summer and this would be the good place to meet each other, and hack together. Would you like to have a topic/device/port to focus on during those days ? -- Kindly Florian -- signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] OpenWrt at CCC Camp
Hi devs, Some of us will be at the CCC Camp this summer and this would be the good place to meet each other, and hack together. Would you like to have a topic/device/hardware port to focus on during those days ? Thank you very much in advance for your answers. -- Kindly, Florian -- signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] upgrades gpsd and reduces memory footprint
Le vendredi 14 décembre 2007, Russell Senior a écrit : Signed-off-by: Russell Senior [EMAIL PROTECTED] Applied in changeset 9774, thanks ! signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Enable harddisk spin-up for WesternDigital NetCenter
Hi Christoph,
Your patch looks good to me, comments below :
Le lundi 21 janvier 2008, Christoph Muellner a écrit :
+
+ /* Western Digital */
+ WDNetCenter,
};
Please use upper case for the device enumeration.
static void __init bcm4780_init(void) {
@@ -134,6 +137,21 @@
schedule_timeout(HZ * 5);
}
+static void __init NetCenter_init(void) {
Please name your function using lower case letters.
+ .leds = {
+ /* register_led changes values, so that we must
exclude
+* here to make NetCenter_init work */
+ //{ .name = LED1, .gpio = 1 1},
+ //{ .name = +5V, .gpio = 1 3},
+ //{ .name = LED4, .gpio = 1 4},
+ //{ .name = +12V, .gpio = 1 6},
Cannot the LEDs work after NetCenter_init was called ?
Thank you very much.
--
Best regards, Florian Fainelli
Email : [EMAIL PROTECTED]
http://openwrt.org
---
signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Fwd: Wanted: i2c subsystem co-maintainer
-- Best regards, Florian Fainelli Email : [EMAIL PROTECTED] http://openwrt.org --- ---BeginMessage--- Hi all, I have a hard time maintaining the i2c subsystem alone. New drivers and, more importantly, subsystem evolutions are submitted much faster than I can review and merge them. I am hearing complaints about this. It has been lasting for a while now and it doesn't seem like the situation is going to improve. Thus, I think it would be better if someone was co-maintaining the i2c subsystem with me. So, if anyone is interested in co-maintaining the i2c subsystem with me, please let me know. The ideal candidate would come from the embedded world, as I have absolutely no experience with this myself and most of the new drivers are for embedded devices, and should have contributed to the kernel in a significant way already. Thanks, -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ---End Message--- signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] how do i extend the search path for an openwrt build?
Hi Robert, Le dimanche 16 mars 2008, Robert P. J. Day a écrit : so there you have it -- the actual commands live in /usr/libexec/sdcc. so, how does one deal with this? should i just arrange to extend my openwrt build search path with /usr/libexec/sdcc? or should i patch the Makefile(s) of any package that needs sdcc to be a little more flexible and be prepared to look elsewhere? what's the correct approach here? thanks. Since Fedora uses, say non-standard ways of packaging sdcc. I would suggest extending the existing RequireCommand macro to check for additionnal sdcc commands. -- Best regards, Florian Fainelli Email : [EMAIL PROTECTED] http://openwrt.org --- signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] hello? fuse-2.7.3?
Hi Robbert, Le lundi 24 mars 2008, Robert P. J. Day a écrit : um ... fuse-2.7.1 is still clearly broken, so upgrading to 2.7.3 would be handy. I think we are all aware of that, and thanks for the patch. We are all getting very busy right now, so it is absolutely no help writing to mention that you sent a patch earlier. We do not drop emails, but it may take some times to read and commit that. -- Best regards, Florian Fainelli Email : [EMAIL PROTECTED] http://openwrt.org --- signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Unable to find kernel module scx200_wdt.ko x86 target
Hi Roberto, Le jeudi 27 mars 2008, Roberto Riggio a écrit : Would it be possible to merge this patch in the svn since otherwise it is not possible to build openwrt for x86. Applied in [10672]. Thanks ! -- Best regards, Florian Fainelli Email : [EMAIL PROTECTED] http://openwrt.org --- signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Fwd: Re: Contact info after Fosdem
Might be of interest to talk with this guy in order not to create yet another embedded framework. ---BeginMessage--- Florian Fainelli wrote: Hi Jelle, You gave me your card after my Fosdem presentation on OpenWrt, so now you have my contact informations. I do not remember your question about OpenWrt, can you as it again ? Hi Florian, Indeed you gave a nice presentation about openWrt. My resulting question/comment was: OpenWrt has a nice system creating device specific kernels and file system. I am working on the emdebian project, and one problems with mainline reposatory is that we can't maintain/create custom kernels for single devices. I was interested to create a more generic way for embedded system developers to create and maintain kernels resulting in more open devices. I am planning to create a new open design based embedded ARM development board and probably make kit available. I am planning this in this year. I hope to create an open SDK based on existing mainline components. So maybe we could work together on sustainable kernel creator system, guidelines Kind regards, Jelle de Jong ---End Message--- signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] br2684 routed runnig on AR7
Hi Juan, Le lundi 31 mars 2008, Juan I. González a écrit : Hi All, In these days I adapted the last patch for br2684 kernel module. This is great work. However, I get an error while applying your patch : [EMAIL PROTECTED]:[~/../trunk]$ patch -p0 --dry-run br2684_route_support.diff patching file target/linux/generic-2.6/patches-2.6.24/601-br2684-routed-support.patch patching file package/br2684ctl/files/br2684ctl patching file package/br2684ctl/patches/101-routed_support.patch patch unexpectedly ends in middle of line patch: malformed patch at line 1062: Can you please fix it ? Thank you very much -- Best regards, Florian Fainelli Email : [EMAIL PROTECTED] http://openwrt.org --- signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] br2684 routed runnig on AR7
Hi Juan, Le mardi 1 avril 2008, Juan I. González a écrit : :( sorry I don't have this ploblem :? Your patch was really malformed, for the last change, it should have been : +@@ -268,11 +285,11 @@ instead of : +@@ -268,11 +320,11 @@ Anyway, applied in changeset 10710. Thanks ! -- Best regards, Florian Fainelli Email : [EMAIL PROTECTED] http://openwrt.org --- signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] mmc-over-gpio driver and fon2100
Hey, Le jeudi 3 avril 2008, Michael Buesch a écrit : Your architecture doesn't seem to implement the GPIO API. Indeed, it needs the generci GPIO patch from #1861 to be applied. -- Best regards, Florian Fainelli Email : [EMAIL PROTECTED] http://openwrt.org --- signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] refactoring ifconfig-ip , cleanups, /etc/preinit
Hi Bastian, Le Saturday 17 May 2008 18:00:13 Bastian Bittorf, vous avez écrit : first base-file which now can work with ip and ifconfig some cleanups for better reading. can anyone explain, what the size-awk thing makes really? This awk call calculates the half of the available RAM to later allow base-files setting up a tmpfs of exactly of this size. -- Best regards, Florian Fainelli Email : [EMAIL PROTECTED] http://openwrt.org --- signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Git repository for Linux kernel mainline merges
Hey Imre, Le Friday 23 May 2008 16:13:59 Imre Kaloz, vous avez écrit : I share Gregers' view, too.. Also, one central git is a chaotic mess for this, every target would need it's own branch.. Think ddwrt's repo :P John and I had a short discussion about that on irc. Basically, the idea behind having git.openwrt.org is to have the following layout : - patches-upstream.git which contains the patches against generic (or quite) generic parts of the kernel - ar7.git, adm5120.git, ifxmips.git ... for every target that is either already merged mainline I do not think this would confuse people, because we do not need to mention such repositories to the end user. This would definitively ease the work to maintain custom drivers and archictecture code and ask mainline maintainers to just pull those repository as a branch. Do you like it better explained that way ? -- Best regards, Florian Fainelli Email : [EMAIL PROTECTED] http://openwrt.org --- signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
