Re: [OpenWrt-Devel] [PATCH] Updated kernel patch in trunk to support brcm47xx BCMA NAND flash
Hi Hauke,
I have modified my patch according to your comments except in two cases.
We want to build one image supporting devices with serial and with nand flash.
This makes it just possible to support one flash type at a time.
Right now flash type can be either NAND or SERIAL. If we want to have two flash
simultaneously then I think we need to have another parameter similar to
bcma_flash_type flash_type What is your opinion ?
cpu_relax();
Why is this needed?
Above change was done according to Florian's comment.
Florian,
Can you clarify it ?
Once these above cases resolve I will provide you the updated patch.
Regards,
Tatha
-Original Message-
From: Hauke Mehrtens [mailto:ha...@hauke-m.de]
Sent: 25 February 2012 19:08
To: Tathagata Das
Cc: 'OpenWrt Development List'; 'Florian Fainelli'
Subject: Re: [PATCH] Updated kernel patch in trunk to support brcm47xx BCMA
NAND flash
Hi Tathagata Das,
I had a look at bthe patch and added some comments, if bcma_nflash_init
is not needed any more where is struct bcma_nflash initilized?
Hauke
On 02/23/2012 02:27 PM, Tathagata Das wrote:
Hi,
Attached is the updated kernel patch to support brcm47xx BCMA NAND flash. I
have used latest trunk source code to create this patch.
Thanks to Florian and Hauke for their comments.
Regards,
Tathagata tathag...@alumnux.com
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 Mehrtens ha...@hauke-m.de
+ * Copyright (C) 2011-2012 Tathagata Das tathag...@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 Fietkau n...@openwrt.org
* Copyright (C) 2010-2011 Hauke Mehrtens ha...@hauke-m.de
+ * Copyright (C) 2011-2012 Tathagata Das tathag...@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 @@
#include asm/mach-bcm47xx/nvram.h
#include asm/mach-bcm47xx/bcm47xx.h
#include asm/mach-bcm47xx/bus.h
+#include linux/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;
+ }
+ 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:
+ return ret;
+}
+
static void early_nvram_init(void)
{
int err = 0;
@@ -185,6 +234,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);
}
I am not happy with the flash driver
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] WBMR-HP-G300H flash image for flashing from original FW?
Hello, It would be make life easier if there is the possibility to flash directly from dd-wrt webif. most likely true... i will investigate how to do so DD-Wrt normally awaits a TRX flash image (HDR0 header) with the noheader flag set. See https://forum.openwrt.org/viewtopic.php?pid=154817#p154817 But I'm still unable to flash openwrt from dd-wrt webif if it has the HDR0 header. It tells me that the firmware is invalid :( I was wrong, there is the stock FW on the device and not dd-wrt. I did some research too and found the images for the device build by brainslayer (http://www.dd-wrt.com/dd-wrtv2/down.php?path=downloads%2Fothers%2Feko%2FBr ainSlayer-V24-preSP2%2F2011%2F12-20-11-r18024%2Fbuffalo_whr_hp_g300n/): whr-hp-g300n-firmware-MULTI.bin The first one (for use with webif) looks completly different. At dd-wrt svn (src/router/Makefile.danube) I found the values for the WBMR-HP-G300H: tools/bufenc/encryptRC4 WBMR-HP-G300H 1.74 Buffalo $(ARCH)-uclibc/aligned.uimage $(ARCH)-uclibc/wmbr-firmware.enc tools/bufenc/mkfw-lan -hw_ver=2 -hcrypt=Buffalo WBMR-HP-G300H WBMR-HP-G300H 1.74 3.02 US-EU-AP-KR-CH-TW-DE-JP mlang8 lan 80002000 80002000 1 $(ARCH)-uclibc/wmbr-firmware.enc $(ARCH)-uclibc/wmbr-firmware_MULTI.enc Ok, tools/bufenc/encryptRC4 seems to be buffalo-enc, tools/bufenc/mkfw-lan buffalo-enc. On the device there are this settings: # cat /etc/BRAND_NAME WBMR-HP-G300H # cat /etc/PRODUCT_NAME WBMR-HP-G300H # cat /etc/HW_VERSION 1 # cat /etc/MAJOR_VERSION 1.74 # cat /etc/MINOR_VERSION 3.02 # cat /etc/LANGUAGE eng-de-fr-it-es-zh_cn-th # cat /etc/SPECIFICATION AP-EU-DE cat /etc/PLATFORM lan Depending on this values I adapted the cmd lines from WHRHPG300N (target/linux/ar71xx/image/Makefile): buffalo-enc -p WBMR-HP-G300H -v 1.74 -i openwrt-lantiq-ar9-WBMR-squashfs.image -o factory.enc buffalo-tag -p WBMR-HP-G300H -b WBMR-HP-G300H -a lan -v 1.74 -m 3.02 -l mlang8 -w 1 -c 0x80002000 -d 0x80002000 -f 1 -r M_ -i factory.enc -o openwrt-lantiq-ar9-WBMR-squashfs-factory_test.trx Then I tried to flash it via webif. Console shows now: cgi.c(3617) UploadCgi :x:btpd STOP-SUCCESS (0 sec) cgi.c(3859) UploadCgi :x:MEMORY CHECK... MidLayer.c(2067) ML_CheckMemory :X:MemFree = 23652 MidLayer.c(2071) ML_CheckMemory :X:Buffers = 4000 MidLayer.c(2075) ML_CheckMemory :X:Cached = 12788 MidLayer.c(2079) ML_CheckMemory :X:Active = 11464 MidLayer.c(2083) ML_CheckMemory :X:Inactive = 7520 cgi.c(4416) UploadCgi :DEBUG:### CFH-mark=WBMR-HP-G300H ### cgi.c(4460) UploadCgi :DEBUG:### NON-CRYPT ### cgi.c(4467) UploadCgi :DEBUG:firm_size:2887884 lTotalSize:2887884 cgi.c(4469) UploadCgi :DEBUG:### cyg_posix_crc32 start ### cgi.c(4471) UploadCgi :DEBUG:### cyg_posix_crc32 end new_CRC32:616818920### cgi.c(4483) UploadCgi :DEBUG:firm_size:2887884 lCRC32:616818920 cgi.c(4486) UploadCgi :DEBUG:CRC OK !UploadCgi(4486) cgi.c(4532) UploadCgi :X:ADSL:AnnexB size 1946177280 Upload seems ok but I got a reset from peer - the upgrade script/bin died I found a image from brainslayer (thread: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=148711postdays=0postorder=ascstart=30, download: http://www.dd-wrt.com/phpBB2/download.php?id=21546, needs registered at dd-wrt forum) for comparing. Maybe someone has a idea whats wrong. With best regards Christoph -- Linux User Group Wernigerode http://www.lug-wr.de/ signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Issue including AR8316 (AR8216) support in RT3052 build
I've been looking around for the right place to patch this but I'm having difficulty finding a similar file that's not lantiq-specific. Can anyone point me in the right direction? I've looked in the entire target/linux/ramips/rt305x and arch/mips/include/asm/mach-ralink but can't find anything On Fri, Feb 24, 2012 at 1:27 PM, Luca Olivetti l...@ventoso.org wrote: Al 24/02/12 19:17, En/na Robert Ryan ha escrit: I see eth0, eth0.1, eth0.2 devices but none of them appear to be functional. I would expect at least the WAN port to work without switch drivers but perhaps I'm mistaken. I can assign IPs and ping the local address but can't ping to/from any external devices. Any assistance would be greatly appreciated. If the AR8316 is like the AR8216 (they use the same driver), it adds vlan headers to incoming packets, and the ethernet driver needs to be patched like this: https://dev.openwrt.org/browser/trunk/target/linux/lantiq/patches/200-owrt-netif_receive_skb.patch Bye -- Luca ___ 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
[OpenWrt-Devel] [PATCH] Makefile for asterisk-1.8 channel driver chan-sccp-b
This package provides a replacement channel driver for asterisk's
chan_skinny. With extended functionality and feature support (shared
lines, realtime config, custom device state and more)
More informatin on http://chan-sccp-b.sourceforge.net and
http://sourceforge.net/projects/chan-sccp-b.
Provided Makefile and Patches have been tested. Currently uses a direct
download from svn repository (trunk), but could be changed to use a
specific revision posted in tags.
I wasn't a 100% sure if i should create a new package in packages or in
package/feeds/packages.
Signed-off-by: Diederik de Grootddegr...@users.sourceforge.net
---
Index: package/asterisk18-chan-sccp-b/files/sccp.openwrt.conf
===
--- package/asterisk18-chan-sccp-b/files/sccp.openwrt.conf(revision 0)
+++ package/asterisk18-chan-sccp-b/files/sccp.openwrt.conf(revision 0)
@@ -0,0 +1,89 @@
+[general]
+servername = Openwrt
+keepalive = 60
+debug = core
+context = default
+dateformat = D/M/Y
+bindaddr = 192.168.1.1
+port = 2000
+disallow=all
+allow=ulaw
+allow=alaw
+allow=gsm
+firstdigittimeout = 16
+digittimeout = 6
+autoanswer_ring_time = 1
+musicclass=default
+language=en
+deny=0.0.0.0/0.0.0.0
+permit=192.168.1.0/255.255.255.0
+protocolversion=17
+
+hotline_enabled=yes
+hotline_context=default
+hotline_extension=111
+
+[SEP001122334455]
+type = device
+description = Phone Number One
+devicetype = 7940
+button = line, 111
+button = line, 113@01:shared
+button = speeddial,Phone 2 Line 1, 112, 112@hint
+
+[SEP00a1a2a3a4a5]
+type = device
+description = Phone Number Two
+devicetype = 7960
+button = line, 112
+button = line, 113@01:shared
+button = speeddial,Phone 1 Line 1, 111, 111@hint
+
+[111]
+id = 1000
+type = line
+pin = 1234
+label = Phone 1 Line 1
+description = Line 111
+mailbox = 10111
+cid_name = Phone 1 CID
+cid_num = 111
+accountcode=79111
+callgroup=1
+pickupgroup=1
+context = default
+incominglimit = 2
+vmnum = 600
+trnsfvm = 1000
+
+[112]
+id = 1001
+type = line
+pin = 1234
+label = Phone 2 Line 1
+description = Line 112
+mailbox = 10112
+cid_name = Phone 2 CID
+cid_num = 112
+accountcode=79112
+callgroup=1
+pickupgroup=1
+context = default
+incominglimit = 2
+vmnum = 600
+trnsfvm = 1000
+
+[113]
+id = 1002
+type = line
+pin = 1234
+label = SharedLine 1
+description = Line 113
+mailbox = 10113
+cid_name = Shared
+cid_num = 113
+accountcode=79113
+incominglimit = 2
+vmnum = 600
+trnsfvm = 1000
+
Index:
package/asterisk18-chan-sccp-b/patches/200-register-file-version.patch
===
---
package/asterisk18-chan-sccp-b/patches/200-register-file-version.patch(revision
0)
+++
package/asterisk18-chan-sccp-b/patches/200-register-file-version.patch(revision
0)
@@ -0,0 +1,19 @@
+--- a/src/chan_sccp.h
b/src/chan_sccp.h
+@@ -172,15 +172,7 @@
+ #define CHECK_LEAKS()
+ #endif
+
+-#define SCCP_FILE_VERSION(file, version) \
+-static void __attribute__((constructor))
__register_file_version(void) \
+-{ \
+-pbx_register_file_version(file, version); \
+-} \
+-static void __attribute__((destructor))
__unregister_file_version(void) \
+-{ \
+-pbx_unregister_file_version(file); \
+-}
++#define SCCP_FILE_VERSION(file, version)
+
+ #define DEV_ID_LOG(x) x ? x-id : SCCP
+
Index: package/asterisk18-chan-sccp-b/Makefile
===
--- package/asterisk18-chan-sccp-b/Makefile(revision 0)
+++ package/asterisk18-chan-sccp-b/Makefile(revision 0)
@@ -0,0 +1,70 @@
+#
+# Copyright (C) 2006 OpenWrt.org
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=asterisk18-chan-sccp-b
+# associated with asterisk version
+PKG_VERSION:=1.8.8.0
+# chan-sccp-b version
+PKG_RELEASE:=V4.0.0
+
+# SVN
+PKG_REV=2797
+PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
+PKG_SOURCE_URL:=https://chan-sccp-b.svn.sourceforge.net/svnroot/chan-sccp-b/trunk
+PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
+PKG_SOURCE_VERSION:=$(PKG_REV)
+PKG_SOURCE_PROTO:=svn
+
+PKG_FIXUP:=libtool
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/asterisk18-chan-sccp-b
+ SUBMENU:=Telephony
+ SECTION:=net
+ CATEGORY:=Network
+ TITLE:=SCCP channel provider for asterisk
+ URL:=http://chan-sccp-b.net.sourceforge.net/
+ MAINTAINER:=Diederik de Grootddegr...@users.sourceforge.net
+ DEPENDS:=+asterisk18 @!TARGET_avr32
+ PROVIDES:=chan-sccp-b
+ MENU:=1
+endef
+
+define Package/asterisk18-chan-sccp-b/Default/description
+ SCCP channel provider for asterisk. It delivers extended functionality
for SCCP phones over chan_skinny delivered
+ by asterisk by default.
+endef
+
+define Build/Configure
+(cd $(PKG_BUILD_DIR); \
+$(TARGET_CONFIGURE_OPTS) \
+./configure \
+--prefix=/usr \
+
Re: [OpenWrt-Devel] Issue including AR8316 (AR8216) support in RT3052 build
Al 27/02/12 18:45, En/na Robert Ryan ha escrit: I've been looking around for the right place to patch this but I'm having difficulty finding a similar file that's not lantiq-specific. Can anyone point me in the right direction? I've looked in the entire target/linux/ramips/rt305x and arch/mips/include/asm/mach-ralink but can't find anything Probably files/drivers/net/ramips.c, it uses netif_rx instead of netif_receive_skb Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] wifi detect returns nothing (openwrt trunk with RB411 R52 (lspci lists radio as AR5413 802.11abg)
Hi, These boxes use to be working but I recently upgraded them to the latest trunk and now my wireless cards are no longer detected. No /etc/config/wireless and trying to generate the file with wifi detect does nothing. Not sure what is going on since everything looks OK. lsmod output is at the end of the email. If I recall, the last build that was working used madwifi and the version I built from trunk uses ath9k. In make menuconfig I remember there was an option for madwifi but I didn't include it as I didn't think it was needed anymore. Did I need that??? Regards, Brian root@OpenWrt:/etc/config# lsmod Module Size Used byTainted: G ath9k 88800 0 ohci_hcd 15760 0 ledtrig_usbdev 2032 0 nf_nat_irc 784 0 nf_conntrack_irc2464 1 nf_nat_irc nf_nat_ftp 976 0 nf_conntrack_ftp4416 1 nf_nat_ftp ipt_MASQUERADE 976 1 iptable_nat 2112 1 nf_nat 9904 4 nf_nat_irc,nf_nat_ftp,ipt_MASQUERADE,iptable_nat xt_conntrack2048 3 xt_CT 1216 0 xt_NOTRACK 448 0 iptable_raw 560 1 xt_state 608 0 nf_conntrack_ipv4 3872 6 iptable_nat,nf_nat nf_defrag_ipv4 624 1 nf_conntrack_ipv4 nf_conntrack 36624 12 nf_nat_irc,nf_conntrack_irc,nf_nat_ftp,nf_conntrack_ftp,ipt_MASQUERADE,iptable_nat,nf_nat,xt_conntrack,xt_CT,xt_NOTRACK,xt_state,nf_conntrack_ipv4 ehci_hcd 32544 0 pppoe 7472 0 pppox 1152 1 pppoe ipt_REJECT 1808 2 xt_TCPMSS 1824 0 ipt_LOG 6048 0 xt_comment 400 0 xt_multiport1104 0 xt_mac 528 0 xt_limit 944 1 iptable_mangle 832 1 iptable_filter 624 1 ip_tables 8864 4 iptable_nat,iptable_raw,iptable_mangle,iptable_filter xt_tcpudp 1632 3 x_tables 1 18 ipt_MASQUERADE,iptable_nat,xt_conntrack,xt_CT,xt_NOTRACK,iptable_raw,xt_state,ipt_REJECT,xt_TCPMSS,ipt_LOG,xt_comment,xt_multiport,xt_mac,xt_limit,iptable_mangle,iptable_filter,ip_tables,xt_tcpudp ppp_async 5952 0 ppp_generic18544 3 pppoe,pppox,ppp_async slhc4368 1 ppp_generic ath9k_common1152 1 ath9k ath9k_hw 347344 2 ath9k,ath9k_common ath14112 3 ath9k,ath9k_common,ath9k_hw mac80211 233280 1 ath9k usbcore98336 4 ohci_hcd,ledtrig_usbdev,ehci_hcd usb_common 480 1 usbcore nls_base4560 1 usbcore crc_ccitt944 1 ppp_async cfg80211 134320 3 ath9k,ath,mac80211 compat 688 0 arc4 768 0 aes_generic29808 0 crypto_algapi 8976 2 arc4,aes_generic leds_gpio 1552 0 gpio_button_hotplug 3184 0 ___ 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)
Hanno, Do we happen to have a list of known issues so that we can work on getting them resolved instead of reverting back to mac80211? On 02/27/2012 03:15 PM, Hanno Schupp wrote: I am not a developer, but I can tell you the ath9k is for b/g/n cards, so that may be the reason. You should use either ath5k or madwifi driver. Personally I found many issues with ath5k integration into openwrt still unresolved in terms of card and device recognition and am consequently in the process to downgrade to madwifi again. Madwifi is no longer developed by the linux open driver project as opposed to ath5k, but the focus and interest of the OpenWrt community has moved on from atheros to ar71xx architecture and thus to ath9k fair and square. As soon as trunk switched one day from madwifi to ath5k on the legacy atheros architecture I started encountering issues - but this is my experience, others may have a different view. On 28 February 2012 09:08, Brian Hutchinsonb.hutch...@gmail.com wrote: Hi, These boxes use to be working but I recently upgraded them to the latest trunk and now my wireless cards are no longer detected. No /etc/config/wireless and trying to generate the file with wifi detect does nothing. Not sure what is going on since everything looks OK. lsmod output is at the end of the email. If I recall, the last build that was working used madwifi and the version I built from trunk uses ath9k. In make menuconfig I remember there was an option for madwifi but I didn't include it as I didn't think it was needed anymore. Did I need that??? Regards, Brian root@OpenWrt:/etc/config# lsmod Module Size Used byTainted: G ath9k 88800 0 ohci_hcd 15760 0 ledtrig_usbdev 2032 0 nf_nat_irc 784 0 nf_conntrack_irc2464 1 nf_nat_irc nf_nat_ftp 976 0 nf_conntrack_ftp4416 1 nf_nat_ftp ipt_MASQUERADE 976 1 iptable_nat 2112 1 nf_nat 9904 4 nf_nat_irc,nf_nat_ftp,ipt_MASQUERADE,iptable_nat xt_conntrack2048 3 xt_CT 1216 0 xt_NOTRACK 448 0 iptable_raw 560 1 xt_state 608 0 nf_conntrack_ipv4 3872 6 iptable_nat,nf_nat nf_defrag_ipv4 624 1 nf_conntrack_ipv4 nf_conntrack 36624 12 nf_nat_irc,nf_conntrack_irc,nf_nat_ftp,nf_conntrack_ftp,ipt_MASQUERADE,iptable_nat,nf_nat,xt_conntrack,xt_CT,xt_NOTRACK,xt_state,nf_conntrack_ipv4 ehci_hcd 32544 0 pppoe 7472 0 pppox 1152 1 pppoe ipt_REJECT 1808 2 xt_TCPMSS 1824 0 ipt_LOG 6048 0 xt_comment 400 0 xt_multiport1104 0 xt_mac 528 0 xt_limit 944 1 iptable_mangle 832 1 iptable_filter 624 1 ip_tables 8864 4 iptable_nat,iptable_raw,iptable_mangle,iptable_filter xt_tcpudp 1632 3 x_tables 1 18 ipt_MASQUERADE,iptable_nat,xt_conntrack,xt_CT,xt_NOTRACK,iptable_raw,xt_state,ipt_REJECT,xt_TCPMSS,ipt_LOG,xt_comment,xt_multiport,xt_mac,xt_limit,iptable_mangle,iptable_filter,ip_tables,xt_tcpudp ppp_async 5952 0 ppp_generic18544 3 pppoe,pppox,ppp_async slhc4368 1 ppp_generic ath9k_common1152 1 ath9k ath9k_hw 347344 2 ath9k,ath9k_common ath14112 3 ath9k,ath9k_common,ath9k_hw mac80211 233280 1 ath9k usbcore98336 4 ohci_hcd,ledtrig_usbdev,ehci_hcd usb_common 480 1 usbcore nls_base4560 1 usbcore crc_ccitt944 1 ppp_async cfg80211 134320 3 ath9k,ath,mac80211 compat 688 0 arc4 768 0 aes_generic29808 0 crypto_algapi 8976 2 arc4,aes_generic leds_gpio 1552 0 gpio_button_hotplug 3184 0 ___ 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 ___ 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)
You can follow the recent changes and discussions here on the developer list. The main issue seems to be how iwinfo does not recognise the physical limitations of the wifi equipment. Everything is 27dBm (possibly from CRDA database?) although in reality it is anywhere between 20dBm and 30dBm depending on the device. Note: I am told this is a limitation of the linux kernel, but I note that madwifi recognised the hardware capabilities correctly. But then again I have written a little extension that just spits out the vendor, id sub-vendor-id and sub-id into dmesg on bootup, I scrape the output and set the device accordingly using a case switch in a custom script. A hack to be sure, but I cannot understand why things are supposedly so hard; I for one do not even code in C properly, I can only write shell scripts and php code. Then the hardware offsets which are now coded into trunk in iwinfo are just simply added to the 27dBm, so you end up with non-sensical power setting and choices up to 37dBm in some cases. Then there are a few other things around the edges, like the recognistion of the Fonera and Meraki devices by MAC addess. Maybe not clean and purist, but it worked like a charm. Now Luci just looks into /proc/cpuinfo by default, which holds no good information for atheros mips devices. I have a nano2, a pico, pico2 HP, an engenius eoc-1650, a fonera plus, a fonera 2.0g, and a dir300a, so I have a reasonable cross-section for testing. And I am sorry to say that device management and power management and display currently in trunk with ath5k is a mess. I am happy to continue to test, as things change but until then I am back to backfire and madwifi. Sorry for the rant, I am grateful someone is taking an interest, and yes I know, we all do that in our spare time (me included). Cheers On 28 February 2012 09:34, Jonathan Bither jonbit...@gmail.com wrote: Hanno, Do we happen to have a list of known issues so that we can work on getting them resolved instead of reverting back to mac80211? On 02/27/2012 03:15 PM, Hanno Schupp wrote: I am not a developer, but I can tell you the ath9k is for b/g/n cards, so that may be the reason. You should use either ath5k or madwifi driver. Personally I found many issues with ath5k integration into openwrt still unresolved in terms of card and device recognition and am consequently in the process to downgrade to madwifi again. Madwifi is no longer developed by the linux open driver project as opposed to ath5k, but the focus and interest of the OpenWrt community has moved on from atheros to ar71xx architecture and thus to ath9k fair and square. As soon as trunk switched one day from madwifi to ath5k on the legacy atheros architecture I started encountering issues - but this is my experience, others may have a different view. On 28 February 2012 09:08, Brian Hutchinsonb.hutch...@gmail.com wrote: Hi, These boxes use to be working but I recently upgraded them to the latest trunk and now my wireless cards are no longer detected. No /etc/config/wireless and trying to generate the file with wifi detect does nothing. Not sure what is going on since everything looks OK. lsmod output is at the end of the email. If I recall, the last build that was working used madwifi and the version I built from trunk uses ath9k. In make menuconfig I remember there was an option for madwifi but I didn't include it as I didn't think it was needed anymore. Did I need that??? Regards, Brian root@OpenWrt:/etc/config# lsmod Module Size Used by Tainted: G ath9k 88800 0 ohci_hcd 15760 0 ledtrig_usbdev 2032 0 nf_nat_irc 784 0 nf_conntrack_irc 2464 1 nf_nat_irc nf_nat_ftp 976 0 nf_conntrack_ftp 4416 1 nf_nat_ftp ipt_MASQUERADE 976 1 iptable_nat 2112 1 nf_nat 9904 4 nf_nat_irc,nf_nat_ftp,ipt_MASQUERADE,iptable_nat xt_conntrack 2048 3 xt_CT 1216 0 xt_NOTRACK 448 0 iptable_raw 560 1 xt_state 608 0 nf_conntrack_ipv4 3872 6 iptable_nat,nf_nat nf_defrag_ipv4 624 1 nf_conntrack_ipv4 nf_conntrack 36624 12 nf_nat_irc,nf_conntrack_irc,nf_nat_ftp,nf_conntrack_ftp,ipt_MASQUERADE,iptable_nat,nf_nat,xt_conntrack,xt_CT,xt_NOTRACK,xt_state,nf_conntrack_ipv4 ehci_hcd 32544 0 pppoe 7472 0 pppox 1152 1 pppoe ipt_REJECT 1808 2 xt_TCPMSS 1824 0 ipt_LOG 6048 0 xt_comment 400 0 xt_multiport 1104 0 xt_mac 528 0 xt_limit 944 1 iptable_mangle 832 1 iptable_filter 624 1 ip_tables 8864 4 iptable_nat,iptable_raw,iptable_mangle,iptable_filter xt_tcpudp 1632 3 x_tables
Re: [OpenWrt-Devel] wifi detect returns nothing (openwrt trunk with RB411 R52 (lspci lists radio as AR5413 802.11abg)
So if I want immediate relief from this, I should drop back to Backfire and turn on madwifi in makemenuconfig? About the only Atheros boxes I have to test with are these two RB411's (one with regular R52 radio and one with the high power version of the R52 radio) and a Buffalo WZR-HP-G300NH (which runs fine with trunk). I would like to work on this problem for trunk. I haven't had the RB411's long and I sure would like to be able to rely on future OpenWRT support. I'm kind of bummed it sounds like nobody cares about supporting this hardware going forward! Regards, Brian ___ 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)
If you wanted immediate relief you could also just select the right driver for your card ;-). Ath5k is the replacement for Madwifi. By selecting ath5k in trunk your radios should operate fine. On 02/27/2012 04:08 PM, Brian Hutchinson wrote: So if I want immediate relief from this, I should drop back to Backfire and turn on madwifi in makemenuconfig? About the only Atheros boxes I have to test with are these two RB411's (one with regular R52 radio and one with the high power version of the R52 radio) and a Buffalo WZR-HP-G300NH (which runs fine with trunk). I would like to work on this problem for trunk. I haven't had the RB411's long and I sure would like to be able to rely on future OpenWRT support. I'm kind of bummed it sounds like nobody cares about supporting this hardware going forward! Regards, Brian ___ 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)
On Mon, Feb 27, 2012 at 4:12 PM, Jonathan Bither jonbit...@gmail.com wrote: If you wanted immediate relief you could also just select the right driver for your card ;-). Ath5k is the replacement for Madwifi. By selecting ath5k in trunk your radios should operate fine. I thought that as I looked at the loaded modules I had running on my Buffalo AP but opkg list | grep -i ath only shows ath9k stuff. ath5k didn't look like it was a package to install. madwifi doesn't show up as an install candidate either. I didn't look to see if ath5k was something I could turn on in the kernel config yet. Regards, Brian ___ 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)
Brian == Brian Hutchinson b.hutch...@gmail.com writes: Brian So if I want immediate relief from this, I should drop back to Brian Backfire and turn on madwifi in makemenuconfig? Except for the recently 'gain calibration timeout' problem which recently I helped bisect and which nbd fixed, ath5k has been working fine for me since last spring. No more madwifi for me. ;-) -- Russell Senior, President russ...@personaltelco.net ___ 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)
On Mon, Feb 27, 2012 at 4:19 PM, Russell Senior russ...@personaltelco.net wrote: Brian == Brian Hutchinson b.hutch...@gmail.com writes: Brian So if I want immediate relief from this, I should drop back to Brian Backfire and turn on madwifi in makemenuconfig? Except for the recently 'gain calibration timeout' problem which recently I helped bisect and which nbd fixed, ath5k has been working fine for me since last spring. No more madwifi for me. ;-) Did you compile it into the kernel or install it as a package? It appears kmod-ath5k isn't available to install using the repos opkg. Regards, Brian ___ 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)
Brian == Brian Hutchinson b.hutch...@gmail.com writes: Brian So if I want immediate relief from this, I should drop back to Brian Backfire and turn on madwifi in makemenuconfig? Except for the recently 'gain calibration timeout' problem which recently I helped bisect and which nbd fixed, ath5k has been working fine for me since last spring. No more madwifi for me. ;-) Brian Did you compile it into the kernel or install it as a package? Brian It appears kmod-ath5k isn't available to install using the Brian repos opkg. I build from trunk. I selected (=y) it from menuconfig under kernel and wireless. You can search in menuconfig with '/'. -- Russell Senior, President russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Alix 2D13 on latest trunk, traces in dmesg on bootup?
By symbolic addresses you mean building it with the symbol table?
CONFIG_KERNEL_KALLSYMS=y
Doing so corrects the problem, making it impossible to debug. If you
mean something else please let me know and I'll be happy to try it.
Being stuck on pre-3 revisions in trunk on the x86 alix2 target is
not some place I'd like to stay.
Thanks,
Adam
On 2/27/12 1:44 AM, Philip Prindeville wrote:
It might also be helpful to get symbolic addresses and not just hex addresses.
On 2/25/12 10:48 AM, Adam Gensler wrote:
Does anyone else have any thoughts into this? Other suggestions I can
try? Seems someone else is seeing the same issue as I've found the
following output sitting on pastebin:
http://pastebin.com/djNfNa3t
These errors match the errors I'm seeing on my system exactly.
I've since reverted to trunk@29844 with a patch kicking it up to the
3.0.18 kernel and I don't see these errors. I went ahead and opened a
ticket on this for tracking purposes:
alix2 - trace messages in dmesg on bootup
https://dev.openwrt.org/ticket/11020
Thanks,
Adam
On 2/22/12 1:02 AM, Adam Gensler wrote:
Just build another one, this time with the following:
# target
CONFIG_TARGET_x86=y
CONFIG_TARGET_x86_alix2=y
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
CONFIG_KERNEL_KALLSYMS=y
#CONFIG_KERNEL_DEBUG_KERNEL=y
#CONFIG_KERNEL_DEBUG_INFO=y
Boots fine, no traces showing up.
Not sure what that means exactly. Buts it's 100% reproducible on three
different alix boards with images from two different build machines.
Adam
On 2/22/12 12:50 AM, Philip Prindeville wrote:
Try leaving CONFIG_KERNEL_KALLSYMS and turn off CONFIG_KERNEL_DEBUG_* ...
On 2/21/12 10:34 PM, Adam Gensler wrote:
Hi Philip,
I suspected that might have been the problem so I did another build real
quick, but I removed your extra commands, and the problem returned in
that build.
So, I ran yet another build, this time, with the following options:
# target
CONFIG_TARGET_x86=y
CONFIG_TARGET_x86_alix2=y
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
#CONFIG_KERNEL_KALLSYMS=y
CONFIG_KERNEL_DEBUG_KERNEL=y
CONFIG_KERNEL_DEBUG_INFO=y
Note, I commented out the CONFIG_KERNEL_KALLSYMS=y. The problems
happens when that is disabled. If I turn that back on,
CONFIG_KERNEL_KALLSYMS=y, the trace messages disappear.
Adam
On 2/22/12 12:30 AM, Philip Prindeville wrote:
Actually, that shouldn't have fixed your problem! (Unless
Heisenberg's Principle comes into effect.)
It was supposed to give us a useful stack trace, however.
You might have had a corrupt build.
Can you try it on several boxes and see if it's reproducible?
-Philip
On 2/21/12 10:10 PM, Adam Gensler wrote:
Hi Philip,
I rebuilt an image with those additional options added. It resolved
the
call traces I was seeing in dmesg. None of them show up now. I'll
admit,
I'm not super familiar with the inner-workings of kernel building. Can
you provide some insight into why this seems to have resolved the
issue?
Attached is the dmesg output from the new image, just in case.
Thanks,
Adam
On 2/21/12 10:31 PM, Philip Prindeville wrote:
On 2/21/12 8:15 PM, Adam Gensler wrote:
Hi all,
I have a handful of Alix 2D13 platforms I've been running trunk
images
on for a while now. I noticed that it was recently kicked up to
kernel
3.2.2. When it boots up now there's a number of traces from insmod.
Attached is the complete output of the boot sequence.
The image was built clean, in a clean pull of trunk, using the
default
alix2 target. I've seen this on multiple alix boards, on images
built on
two completely separate build servers so I don't think its
related to
how I'm building the image.
Any suggestions on how to troubleshoot this?
Thanks in advance,
Adam
Please do the following:
% mkdir ~/.openwrt
% cat ~/.openwrt/defconfig
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
CONFIG_KERNEL_KALLSYMS=y
CONFIG_KERNEL_DEBUG_KERNEL=y
CONFIG_KERNEL_DEBUG_INFO=y
^D
% rm -rf tmp .config
% make defconfig
% make target/linux/{clean,compile} world V=99
%
and try it again.
Thanks,
-Philip
___
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] Alix 2D13 on latest trunk, traces in dmesg on bootup?
You should be able to get a stack trace with gdb and the unstripped kernel, or
else just do it by hand with:
.tmp_System.map
in your build_dir/linux-x86_alix2/linux-3.2.2/ directory.
Maybe someone else like Felix or Jo-Philipp can give better suggestions?
-Philip
On 2/27/12 5:53 PM, Adam Gensler wrote:
By symbolic addresses you mean building it with the symbol table?
CONFIG_KERNEL_KALLSYMS=y
Doing so corrects the problem, making it impossible to debug. If you
mean something else please let me know and I'll be happy to try it.
Being stuck on pre-3 revisions in trunk on the x86 alix2 target is
not some place I'd like to stay.
Thanks,
Adam
On 2/27/12 1:44 AM, Philip Prindeville wrote:
It might also be helpful to get symbolic addresses and not just hex
addresses.
On 2/25/12 10:48 AM, Adam Gensler wrote:
Does anyone else have any thoughts into this? Other suggestions I can
try? Seems someone else is seeing the same issue as I've found the
following output sitting on pastebin:
http://pastebin.com/djNfNa3t
These errors match the errors I'm seeing on my system exactly.
I've since reverted to trunk@29844 with a patch kicking it up to the
3.0.18 kernel and I don't see these errors. I went ahead and opened a
ticket on this for tracking purposes:
alix2 - trace messages in dmesg on bootup
https://dev.openwrt.org/ticket/11020
Thanks,
Adam
On 2/22/12 1:02 AM, Adam Gensler wrote:
Just build another one, this time with the following:
# target
CONFIG_TARGET_x86=y
CONFIG_TARGET_x86_alix2=y
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
CONFIG_KERNEL_KALLSYMS=y
#CONFIG_KERNEL_DEBUG_KERNEL=y
#CONFIG_KERNEL_DEBUG_INFO=y
Boots fine, no traces showing up.
Not sure what that means exactly. Buts it's 100% reproducible on three
different alix boards with images from two different build machines.
Adam
On 2/22/12 12:50 AM, Philip Prindeville wrote:
Try leaving CONFIG_KERNEL_KALLSYMS and turn off CONFIG_KERNEL_DEBUG_* ...
On 2/21/12 10:34 PM, Adam Gensler wrote:
Hi Philip,
I suspected that might have been the problem so I did another build real
quick, but I removed your extra commands, and the problem returned in
that build.
So, I ran yet another build, this time, with the following options:
# target
CONFIG_TARGET_x86=y
CONFIG_TARGET_x86_alix2=y
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
#CONFIG_KERNEL_KALLSYMS=y
CONFIG_KERNEL_DEBUG_KERNEL=y
CONFIG_KERNEL_DEBUG_INFO=y
Note, I commented out the CONFIG_KERNEL_KALLSYMS=y. The problems
happens when that is disabled. If I turn that back on,
CONFIG_KERNEL_KALLSYMS=y, the trace messages disappear.
Adam
On 2/22/12 12:30 AM, Philip Prindeville wrote:
Actually, that shouldn't have fixed your problem! (Unless
Heisenberg's Principle comes into effect.)
It was supposed to give us a useful stack trace, however.
You might have had a corrupt build.
Can you try it on several boxes and see if it's reproducible?
-Philip
On 2/21/12 10:10 PM, Adam Gensler wrote:
Hi Philip,
I rebuilt an image with those additional options added. It resolved
the
call traces I was seeing in dmesg. None of them show up now. I'll
admit,
I'm not super familiar with the inner-workings of kernel building. Can
you provide some insight into why this seems to have resolved the
issue?
Attached is the dmesg output from the new image, just in case.
Thanks,
Adam
On 2/21/12 10:31 PM, Philip Prindeville wrote:
On 2/21/12 8:15 PM, Adam Gensler wrote:
Hi all,
I have a handful of Alix 2D13 platforms I've been running trunk
images
on for a while now. I noticed that it was recently kicked up to
kernel
3.2.2. When it boots up now there's a number of traces from insmod.
Attached is the complete output of the boot sequence.
The image was built clean, in a clean pull of trunk, using the
default
alix2 target. I've seen this on multiple alix boards, on images
built on
two completely separate build servers so I don't think its
related to
how I'm building the image.
Any suggestions on how to troubleshoot this?
Thanks in advance,
Adam
Please do the following:
% mkdir ~/.openwrt
% cat ~/.openwrt/defconfig
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
CONFIG_KERNEL_KALLSYMS=y
CONFIG_KERNEL_DEBUG_KERNEL=y
CONFIG_KERNEL_DEBUG_INFO=y
^D
% rm -rf tmp .config
% make defconfig
% make target/linux/{clean,compile} world V=99
%
and try it again.
Thanks,
-Philip
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Alix 2D13 on latest trunk, traces in dmesg on bootup?
Good idea, see inline:
On 2/27/12 11:14 PM, Philip Prindeville wrote:
Two questions:
If you keep 29981 (and above) and set LINUX_VERSION back to 2.6.39.4 what
happens?
[adam] Works fine, 29981 with kernel 2.6.39.4 on the alix2 target boots
without traces in dmesg.
If you build a x86/generic kernel with LINUX_VERSION=3.2.2 what happens?
[adam] Same problem as alix2 target on 3.2.2. Traces in dmesg when
building the generic x86 target using kernel version 3.2.2.
Perhaps this points to a patch issue within the 3.2 patch set?
On 2/27/12 9:01 PM, Adam Gensler wrote:
Confirmed, this issue first appears when the kernel was bumped to 3.2.1
in this change set:
https://dev.openwrt.org/changeset/29981/trunk
29980, which still uses 2.6.39.4 works fine. 29981, which moves to 3.2.1
has the previously mentioned traces in dmesg on boot up.
On 2/27/12 7:53 PM, Adam Gensler wrote:
By symbolic addresses you mean building it with the symbol table?
CONFIG_KERNEL_KALLSYMS=y
Doing so corrects the problem, making it impossible to debug. If you
mean something else please let me know and I'll be happy to try it.
Being stuck on pre-3 revisions in trunk on the x86 alix2 target is
not some place I'd like to stay.
Thanks,
Adam
On 2/27/12 1:44 AM, Philip Prindeville wrote:
It might also be helpful to get symbolic addresses and not just hex
addresses.
On 2/25/12 10:48 AM, Adam Gensler wrote:
Does anyone else have any thoughts into this? Other suggestions I can
try? Seems someone else is seeing the same issue as I've found the
following output sitting on pastebin:
http://pastebin.com/djNfNa3t
These errors match the errors I'm seeing on my system exactly.
I've since reverted to trunk@29844 with a patch kicking it up to the
3.0.18 kernel and I don't see these errors. I went ahead and opened a
ticket on this for tracking purposes:
alix2 - trace messages in dmesg on bootup
https://dev.openwrt.org/ticket/11020
Thanks,
Adam
On 2/22/12 1:02 AM, Adam Gensler wrote:
Just build another one, this time with the following:
# target
CONFIG_TARGET_x86=y
CONFIG_TARGET_x86_alix2=y
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
CONFIG_KERNEL_KALLSYMS=y
#CONFIG_KERNEL_DEBUG_KERNEL=y
#CONFIG_KERNEL_DEBUG_INFO=y
Boots fine, no traces showing up.
Not sure what that means exactly. Buts it's 100% reproducible on three
different alix boards with images from two different build machines.
Adam
On 2/22/12 12:50 AM, Philip Prindeville wrote:
Try leaving CONFIG_KERNEL_KALLSYMS and turn off
CONFIG_KERNEL_DEBUG_* ...
On 2/21/12 10:34 PM, Adam Gensler wrote:
Hi Philip,
I suspected that might have been the problem so I did another
build real
quick, but I removed your extra commands, and the problem returned in
that build.
So, I ran yet another build, this time, with the following options:
# target
CONFIG_TARGET_x86=y
CONFIG_TARGET_x86_alix2=y
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
#CONFIG_KERNEL_KALLSYMS=y
CONFIG_KERNEL_DEBUG_KERNEL=y
CONFIG_KERNEL_DEBUG_INFO=y
Note, I commented out the CONFIG_KERNEL_KALLSYMS=y. The problems
happens when that is disabled. If I turn that back on,
CONFIG_KERNEL_KALLSYMS=y, the trace messages disappear.
Adam
On 2/22/12 12:30 AM, Philip Prindeville wrote:
Actually, that shouldn't have fixed your problem! (Unless
Heisenberg's Principle comes into effect.)
It was supposed to give us a useful stack trace, however.
You might have had a corrupt build.
Can you try it on several boxes and see if it's reproducible?
-Philip
On 2/21/12 10:10 PM, Adam Gensler wrote:
Hi Philip,
I rebuilt an image with those additional options added. It resolved
the
call traces I was seeing in dmesg. None of them show up now. I'll
admit,
I'm not super familiar with the inner-workings of kernel
building. Can
you provide some insight into why this seems to have resolved the
issue?
Attached is the dmesg output from the new image, just in case.
Thanks,
Adam
On 2/21/12 10:31 PM, Philip Prindeville wrote:
On 2/21/12 8:15 PM, Adam Gensler wrote:
Hi all,
I have a handful of Alix 2D13 platforms I've been running trunk
images
on for a while now. I noticed that it was recently kicked up to
kernel
3.2.2. When it boots up now there's a number of traces from
insmod.
Attached is the complete output of the boot sequence.
The image was built clean, in a clean pull of trunk, using the
default
alix2 target. I've seen this on multiple alix boards, on images
built on
two completely separate build servers so I don't think its
related to
how I'm building the image.
Any suggestions on how to troubleshoot this?
Thanks in advance,
Adam
Please do the following:
% mkdir ~/.openwrt
% cat ~/.openwrt/defconfig
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
CONFIG_KERNEL_KALLSYMS=y
CONFIG_KERNEL_DEBUG_KERNEL=y
CONFIG_KERNEL_DEBUG_INFO=y
^D
% rm -rf tmp .config
% make defconfig
% make target/linux/{clean,compile} world V=99
%
and try it again.
Thanks,
-Philip
___
openwrt-devel mailing list
[OpenWrt-Devel] [PATCH] ECDSA support in openssh and openssl
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
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] [PATCH] Updated kernel patch in trunk to support brcm47xx BCMA NAND flash
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. Regards, Tathagata tathag...@alumnux.com 9991-bcm47xx-bcma-nandflash.patch Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
