Re: [OpenWrt-Devel] [PATCH] AA: ar71xx: Add support for TP-LINK WR847N v8
Well, I’d rather not use Gmail web to send patch. Sorry again. Signed-off-by: Jaehoon You teslam...@gmail.com This patch adds TP-LINK WR847N v8 which is rebrand model of WR841N v8 with updated bootloader. There's no hardware difference between WR847N v8 and WR841N(D) v8, so I modify Makefile and compile, flashing it on web interface without problem. This patch applies to AA trunk(r39408). Signed-off-by: Jaehoon You --- target/linux/ar71xx/image/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile index 9ebe486..a4a5d4a 100644 --- a/target/linux/ar71xx/image/Makefile +++ b/target/linux/ar71xx/image/Makefile @@ -879,6 +879,7 @@ $(eval $(call SingleProfile,TPLINK-LZMA,$(fs_64kraw),TLWR703,tl-wr703n-v1,TL-WR7 $(eval $(call SingleProfile,TPLINK-LZMA,$(fs_64kraw),TLWR740NV4,tl-wr740n-v4,TL-WR741ND-v4,ttyATH0,115200,0x0744,1,4Mlzma)) $(eval $(call SingleProfile,TPLINK-LZMA,$(fs_64kraw),TLWR741NV4,tl-wr741nd-v4,TL-WR741ND-v4,ttyATH0,115200,0x07410004,1,4Mlzma)) $(eval $(call SingleProfile,TPLINK-LZMA,$(fs_64kraw),TLWR841NV8,tl-wr841n-v8,TL-WR841N-v8,ttyS0,115200,0x08410008,1,4Mlzma)) +$(eval $(call SingleProfile,TPLINK-LZMA,$(fs_64kraw),TLWR847NV8,tl-wr847n-v8,TL-WR841N-v8,ttyS0,115200,0x08470008,1,4Mlzma)) $(eval $(call SingleProfile,TPLINK-LZMA,$(fs_64kraw),TLWR1041,tl-wr1041n-v2,TL-WR1041N-v2,ttyS0,115200,0x10410002,1,4Mlzma)) $(eval $(call SingleProfile,TPLINK-LZMA,$(fs_64kraw),TLWR2543,tl-wr2543-v1,TL-WR2543N,ttyS0,115200,0x25430001,1,8Mlzma,-v 3.13.99)) $(eval $(call SingleProfile,TPLINK-LZMA,$(fs_64kraw),TLWDR3600V1,tl-wdr3600-v1,TL-WDR4300,ttyS0,115200,0x3601,1,8Mlzma)) @@ -923,7 +924,7 @@ $(eval $(call MultiProfile,TLWA901,TLWA901NV1 TLWA901NV2)) $(eval $(call MultiProfile,TLWA7510,TLWA7510NV1)) $(eval $(call MultiProfile,TLWR740,TLWR740NV1 TLWR740NV3 TLWR740NV4)) $(eval $(call MultiProfile,TLWR741,TLWR741NV1 TLWR741NV2 TLWR741NV4)) -$(eval $(call MultiProfile,TLWR841,TLWR841NV15 TLWR841NV3 TLWR841NV5 TLWR841NV7 TLWR841NV8)) +$(eval $(call MultiProfile,TLWR841,TLWR841NV15 TLWR841NV3 TLWR841NV5 TLWR841NV7 TLWR841NV8 TLWR847NV8)) $(eval $(call MultiProfile,TLWR941,TLWR941NV2 TLWR941NV3 TLWR941NV4)) $(eval $(call MultiProfile,TLWDR4300,TLWDR3600V1 TLWDR4300V1 TLWDR4310V1)) $(eval $(call MultiProfile,UBNT,UBNTAIRROUTER UBNTRS UBNTRSPRO UBNTLSSR71 UBNTBULLETM UBNTROCKETM UBNTNANOM UBNTUNIFI UBNTUNIFIOUTDOOR)) --- target/linux/ar71xx/image/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile index 9ebe486..a4a5d4a 100644 --- a/target/linux/ar71xx/image/Makefile +++ b/target/linux/ar71xx/image/Makefile @@ -879,6 +879,7 @@ $(eval $(call SingleProfile,TPLINK-LZMA,$(fs_64kraw),TLWR703,tl-wr703n-v1,TL-WR7 $(eval $(call SingleProfile,TPLINK-LZMA,$(fs_64kraw),TLWR740NV4,tl-wr740n-v4,TL-WR741ND-v4,ttyATH0,115200,0x0744,1,4Mlzma)) $(eval $(call SingleProfile,TPLINK-LZMA,$(fs_64kraw),TLWR741NV4,tl-wr741nd-v4,TL-WR741ND-v4,ttyATH0,115200,0x07410004,1,4Mlzma)) $(eval $(call SingleProfile,TPLINK-LZMA,$(fs_64kraw),TLWR841NV8,tl-wr841n-v8,TL-WR841N-v8,ttyS0,115200,0x08410008,1,4Mlzma)) +$(eval $(call SingleProfile,TPLINK-LZMA,$(fs_64kraw),TLWR847NV8,tl-wr847n-v8,TL-WR841N-v8,ttyS0,115200,0x08470008,1,4Mlzma)) $(eval $(call SingleProfile,TPLINK-LZMA,$(fs_64kraw),TLWR1041,tl-wr1041n-v2,TL-WR1041N-v2,ttyS0,115200,0x10410002,1,4Mlzma)) $(eval $(call SingleProfile,TPLINK-LZMA,$(fs_64kraw),TLWR2543,tl-wr2543-v1,TL-WR2543N,ttyS0,115200,0x25430001,1,8Mlzma,-v 3.13.99)) $(eval $(call SingleProfile,TPLINK-LZMA,$(fs_64kraw),TLWDR3600V1,tl-wdr3600-v1,TL-WDR4300,ttyS0,115200,0x3601,1,8Mlzma)) @@ -923,7 +924,7 @@ $(eval $(call MultiProfile,TLWA901,TLWA901NV1 TLWA901NV2)) $(eval $(call MultiProfile,TLWA7510,TLWA7510NV1)) $(eval $(call MultiProfile,TLWR740,TLWR740NV1 TLWR740NV3 TLWR740NV4)) $(eval $(call MultiProfile,TLWR741,TLWR741NV1 TLWR741NV2 TLWR741NV4)) -$(eval $(call MultiProfile,TLWR841,TLWR841NV15 TLWR841NV3 TLWR841NV5 TLWR841NV7 TLWR841NV8)) +$(eval $(call MultiProfile,TLWR841,TLWR841NV15 TLWR841NV3 TLWR841NV5 TLWR841NV7 TLWR841NV8 TLWR847NV8)) $(eval $(call MultiProfile,TLWR941,TLWR941NV2 TLWR941NV3 TLWR941NV4)) $(eval $(call MultiProfile,TLWDR4300,TLWDR3600V1 TLWDR4300V1 TLWDR4310V1)) $(eval $(call MultiProfile,UBNT,UBNTAIRROUTER UBNTRS UBNTRSPRO UBNTLSSR71 UBNTBULLETM UBNTROCKETM UBNTNANOM UBNTUNIFI UBNTUNIFIOUTDOOR)) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [x86_64]: adding ATA GENERIC + PIIX to support IDE HDD
On Wed, 05 Feb 2014 15:50:15 +0100, Alexandru Ardelean ardeleana...@gmail.com wrote: Seems that the x86_64 build of OpenWRT hangs on boot in KVM and QEMU. After looking over the 'target/linux/x86_64' folder in comparison with 'target/linux/x86' I've narrowed it down to just these 2 options that have to explicitly be set in the config-default file of the x86_64 build. NAK. x86_64 won't have legacy support, so please use AHCI on both KVM/QEMU for this target. Imre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] mt7620 wifi
On 5 February 2014 09:21, Helmut Schaa helmut.sc...@googlemail.com wrote: So, you ported the code from the ralink rt2860 driver, right? I haven't looked into newer ralink chips at all. Did you check if any MAC layer changes regarding RX and TX rings exist? Yes, from rt2860v2 2.7.1.6 to be precise. Yes I did the mac registers init too. There are several new registers they initialize. I tried to integrate mac init to the existing function. Do you think I should try to do it separately? No, should be fine that way (for testing) I guess. Did you check if the interrupt handler is called after setting the device up (/proc/interrupts)? Just as a first evidence of life? Hmm.. If I configure it as ap, yes: CPU0 5: 28 MIPS 1010.ethernet 6: 38912 MIPS rt2800_wmac 7: 204558 MIPS timer 9: 0 INTC 1100.timer 20:521 INTC serial 25: 2 INTC gsw ERR: 0 Good, so at least something happens :D Might make sense to add some code to the interrupt handler to see which interrupts get fired. Do you mean plat_irq_dispatch() from arch/mips/ralink/irq.c ? But if I put it in monitor mode (either via config or iw command) interrupt counter remains zero. What does it mean? So, it seems as if the RX path is not working at all. But that can have several reasons ... Did you check with a second wifi device if the card transmits any frames in AP mode? Beacons? Only with android tablet with wifi scanner. Do you think I should try a better scanner (kismet?) ? Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] bcm63xx: decrease bcm6348 SPI FIFO size
On Thu, Feb 6, 2014 at 4:14 AM, Florian Fainelli flor...@openwrt.org wrote: Hi, Le 02/02/2014 12:01, dani a écrit : Decrease the SPI FIFO size in BMC6348 boards to avoid random reads/writes. The parameter BCM63XX_SPI_MAX_PREPEND is causing the SPI driver exceeds the hardware capabilities when reading transfer lengths over 58 bytes. Decreasing the SPI fifo size exactly the BCM63XX_SPI_MAX_PREPEND lenght solves the problem. I noticed it when I connected an external SPI flash memory to my old livebox1, the flash memory was correctly recognized as another mtd device with its partition, and everything seemed to be going well. When using dd, with block sizes =58 all reads went fine, but over 58 all the reads were totally random. I know the SPI driver is far from being perfect, but I think It's a good idea to fix this if someone decides to use the BCM6348 SPI interface in his board. With this patch the random reads never happens, when you exceed the limit it returns the error unable to do transfers larger than FIFO size (%i %i) As done before the patch. It seems the driver still needs further work. The patch looks correct on the principle, but I would do that in the spi driver directly for two reasons: - you would not need to duplicate the prepend count value in dev-spi.c - you would make this work for 6358 and 6368 as well I did not encounter this problem on my 6368 with SPI connected flash, so I suspect this only affects 6338/6348. Also I still wonder why With this patch the random reads never happens, when you exceed the limit it returns the error unable to do transfers larger than FIFO size (%i %i) this happens, the m25p80 fixup should prevent it (on reads) and automatically split any reads FIFO size into appropriate chunks (writes will be broken because it does not do that yet there). Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Will OpenWrt apply for Google Summer of Code 2014 as organization?
Hi all, I am a student programmer and an OpenWrt fan for long time. I am familiar with wireless routers and OpenWrt. I would like to know if the OpenWrt has any chance to be in the GSoC this year. Many thanks. Hao ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] mt7620 wifi
On Thu, Feb 6, 2014 at 11:40 AM, Roman Yeryomin leroi.li...@gmail.com wrote: On 5 February 2014 09:21, Helmut Schaa helmut.sc...@googlemail.com wrote: So, you ported the code from the ralink rt2860 driver, right? I haven't looked into newer ralink chips at all. Did you check if any MAC layer changes regarding RX and TX rings exist? Yes, from rt2860v2 2.7.1.6 to be precise. Yes I did the mac registers init too. There are several new registers they initialize. I tried to integrate mac init to the existing function. Do you think I should try to do it separately? No, should be fine that way (for testing) I guess. Did you check if the interrupt handler is called after setting the device up (/proc/interrupts)? Just as a first evidence of life? Hmm.. If I configure it as ap, yes: CPU0 5: 28 MIPS 1010.ethernet 6: 38912 MIPS rt2800_wmac 7: 204558 MIPS timer 9: 0 INTC 1100.timer 20:521 INTC serial 25: 2 INTC gsw ERR: 0 Good, so at least something happens :D Might make sense to add some code to the interrupt handler to see which interrupts get fired. Do you mean plat_irq_dispatch() from arch/mips/ralink/irq.c ? I thought about rt2800mmio_interrupt. But if I put it in monitor mode (either via config or iw command) interrupt counter remains zero. What does it mean? So, it seems as if the RX path is not working at all. But that can have several reasons ... Did you check with a second wifi device if the card transmits any frames in AP mode? Beacons? Only with android tablet with wifi scanner. Do you think I should try a better scanner (kismet?) ? Just use a second linux machine with a reasonable wifi card (ath9k will do for example), put it into monitor mode and run tcpdump/wireshark on it ... Helmut ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] mt7620 wifi
On 6 February 2014 13:01, Helmut Schaa helmut.sc...@googlemail.com wrote: On Thu, Feb 6, 2014 at 11:40 AM, Roman Yeryomin leroi.li...@gmail.com wrote: On 5 February 2014 09:21, Helmut Schaa helmut.sc...@googlemail.com wrote: So, you ported the code from the ralink rt2860 driver, right? I haven't looked into newer ralink chips at all. Did you check if any MAC layer changes regarding RX and TX rings exist? Yes, from rt2860v2 2.7.1.6 to be precise. Yes I did the mac registers init too. There are several new registers they initialize. I tried to integrate mac init to the existing function. Do you think I should try to do it separately? No, should be fine that way (for testing) I guess. Did you check if the interrupt handler is called after setting the device up (/proc/interrupts)? Just as a first evidence of life? Hmm.. If I configure it as ap, yes: CPU0 5: 28 MIPS 1010.ethernet 6: 38912 MIPS rt2800_wmac 7: 204558 MIPS timer 9: 0 INTC 1100.timer 20:521 INTC serial 25: 2 INTC gsw ERR: 0 Good, so at least something happens :D Might make sense to add some code to the interrupt handler to see which interrupts get fired. Do you mean plat_irq_dispatch() from arch/mips/ralink/irq.c ? I thought about rt2800mmio_interrupt. then it's these two: INT_SOURCE_CSR_TBTT INT_SOURCE_CSR_PRE_TBTT But if I put it in monitor mode (either via config or iw command) interrupt counter remains zero. What does it mean? So, it seems as if the RX path is not working at all. But that can have several reasons ... Did you check with a second wifi device if the card transmits any frames in AP mode? Beacons? Only with android tablet with wifi scanner. Do you think I should try a better scanner (kismet?) ? Just use a second linux machine with a reasonable wifi card (ath9k will do for example), put it into monitor mode and run tcpdump/wireshark on it ... I will check it little bit later today. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v4] DGN3500 (all known variants) factory image building support
This patch adds factory image building for the DGN3500, all variants. The images can be used directly in the update dialog in the web interface of the stock firmware and via the special Sercomm bootmode and a special windows flashing utility (allegedly present in the CD that came with the device -- but it's also compatible with the NSLU2 Upgrade_207_XP utility.) The special bootmode can be activated by turning the device on while holding the reset button pressed, then releasing it when the power led starts blinking red and green. Please notice that if using the 207 utility, it will always report that the flashing failed even though it completed successfully. Just power cycle the router manually after the utility reports the failure and OpenWRT will boot. This same utility (despite reporting failure in this case too) can revert a DGN3500 (any variant) to the appropriate stock Netgear firmware. This patch is a heavily modified version of a package I found on the OpenWRT forum with a couple fixes and features added -- mainly the generation of all the different image variants to support all known models directly, atm known variants are AnnexA-WW, AnnexA-NA and AnnexB-DE/GR. I tested the patch successfully on my device. The v3 fixes a bug in the checksum appending algorithm that made the images unflashable if the checksum happened to be 0x1000 and another bug that caused the pid signature to be written in the wrong place. This v4 is just a resubmit as it didn't appear in patchwork, I'm sorry for all the noise I caused in this list. Signed-off-by: Marco Antonio Mauro marcu...@gmail.com -- dgn3500-factory-final-v3.patch Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] MyNET N750 - Actually turn the LNA on.
I guess you got that piece of code wrong. The first argument to the ath79_wmac_set_ext_lna_gpio function refers to the TX chain, not the value to be written to the GPIO. So everything is fine here. Regards, Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] MyNET N750 - Actually turn the LNA on.
On 07/02/14 03:18, Felix Kaechele wrote: I guess you got that piece of code wrong. The first argument to the ath79_wmac_set_ext_lna_gpio function refers to the TX chain, not the value to be written to the GPIO. So everything is fine here. Without sounding rude here, are you sure? My look was first prompted by this comment on my web site: I’m see a similar issue as Andy, with the latest builds. To get connected with 5GHz, you need to be sitting almost in-front of the N750. Steve, could you explain the difference of the patch you submitted and the code that replaced your patch. It was my understanding that you were setting the GPIO pins to high to fix the reception issues. On the new code it seems that one is set to high and the other one to low. Your code: 181 gpio_request_one(MYNET_N750_GPIO_EXTERNAL_LNA0, 182 GPIOF_OUT_INIT_HIGH | GPIOF_EXPORT_DIR_FIXED, 183 “External LNA0″); 184 gpio_request_one(MYNET_N750_GPIO_EXTERNAL_LNA1, 185 GPIOF_OUT_INIT_HIGH | GPIOF_EXPORT_DIR_FIXED, 186 “External LNA1″); The new code: ath79_wmac_set_ext_lna_gpio(0, MYNET_N750_GPIO_EXTERNAL_LNA0); ath79_wmac_set_ext_lna_gpio(1, MYNET_N750_GPIO_EXTERNAL_LNA1); In this, 'your patch' was the original patch to fix this by yourself. This was heavily refactored before merging into trunk. The original code seems to be setting both to high - whereas the new code seems only to set one high. After applying this patch, the reply to the comment states: Thanks Steve, I just tested the image with the new patch. I can confirm that it is working a lot better While it could be a random coincidence, I don't have any evidence further than this to say that it isn't. If others have an N750 that they could test on, I have a built image with this patch included at: http://openwrt.crc.id.au/r39504/ Builds on my site earlier than r39499 do not have this patch applied as a comparison. I would love to get further testing before we write this off - just to make sure. -- Steven Haigh Email: net...@crc.id.au Web: https://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 Fax: (03) 8338 0299 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] MyNET N750 - Actually turn the LNA on.
On 07/02/14 08:37, Andy Botting wrote: Steve, If others have an N750 that they could test on, I have a built image with this patch included at: http://openwrt.crc.id.au/r39504/ Is your LNA patch applicable to the N600? I've got a couple of them sitting around after I tried them out and had signal issues (presumably before the signal fix patches made it to trunk). Hi Andy, I do have an N600 - and I can confirm this works as advertised. The settings related to the LNAs for the N600 are the same as the default N750 BEFORE the patch. As such, I'm not quite sure of the problem - if its non-existent, coincidence, or it is a quirk of the N750. That's why I'd like to get more testers / feedback from owners of N750 devices to check... -- Steven Haigh Email: net...@crc.id.au Web: https://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 Fax: (03) 8338 0299 signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] MyNET N750 - Actually turn the LNA on.
Steve, If others have an N750 that they could test on, I have a built image with this patch included at: http://openwrt.crc.id.au/r39504/ Is your LNA patch applicable to the N600? I've got a couple of them sitting around after I tried them out and had signal issues (presumably before the signal fix patches made it to trunk). cheers, Andy ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] mt7620 wifi
On 6 February 2014 13:27, Roman Yeryomin leroi.li...@gmail.com wrote: On 6 February 2014 13:01, Helmut Schaa helmut.sc...@googlemail.com wrote: On Thu, Feb 6, 2014 at 11:40 AM, Roman Yeryomin leroi.li...@gmail.com wrote: On 5 February 2014 09:21, Helmut Schaa helmut.sc...@googlemail.com wrote: Did you check with a second wifi device if the card transmits any frames in AP mode? Beacons? Only with android tablet with wifi scanner. Do you think I should try a better scanner (kismet?) ? Just use a second linux machine with a reasonable wifi card (ath9k will do for example), put it into monitor mode and run tcpdump/wireshark on it ... I will check it little bit later today. So, no, I couldn't catch any frames in the air with this (in monitor mode): tcpdump -i wlan0 -X ether src mt7620 mac Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Fix rp-pppoe linkage
On 12/16/2013 09:57 AM, Nils Rennebarth wrote: From: Nils Rennebarth nils.renneba...@teldat.de Do not link against libevent if present on your target. That lib is completely different from the libevent in rp-pppoe. The lib is part of the dependencies, so no -L and -l are necessary anyway. Signed-off-by: Nils Rennebarth nils.renneba...@teldat.com --- net/rp-pppoe/patches/110-Makefile.patch | 11 +++ 1 file changed, 11 insertions(+) create mode 100644 net/rp-pppoe/patches/110-Makefile.patch Thank you for the patches, they are applied in r39516 and 39517. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Update authsae to latest version
On 12/15/2013 11:49 PM, Etienne CHAMPETIER wrote: Only compile tested but the changes are minimal https://github.com/cozybit/authsae/compare/f5693a3...1d1a122 Signed-off-by: Etienne CHAMPETIER etienne.champet...@free.fr --- package/network/services/authsae/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Thank you for the patch, it was applied in r39518. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] MyNET N750 - Actually turn the LNA on.
Images found here: http://openwrt.crc.id.au/ Steve The code you first sent was merged with revision 39213 for the N750. If I use your image with this patch ( the one marked ) r39211 - I can get connected with both radios. LuCI responds in a timely fashion. There is no lag when applying changes. They cleaned up the code in revision r39217, I couldn't find the definition for the function they're using ath79_wmac_set_ext_lna_gpio But all builds after that have issues with the radios, poor performance on the 5GHz radios - LuCI lags on the page that setups the WiFi radios. With the image you have as r39499 with the patch - the router behaves as with the r39213 with patch image. ( the first fix you sent ) I wanted to verify the state of the GPIOs on the kernel under the running linux system - that is why I asked if there was a way to verify the State of the GPIOs in your blog. Luis Garcia ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [packages] libqmi: update to 1.8.0
On 12/12/2013 07:05 PM, Tim Harvey wrote: Signed-off-by: Tim Harvey thar...@gateworks.com --- libs/libqmi/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libs/libqmi/Makefile b/libs/libqmi/Makefile index a9db3c0..f094439 100644 --- a/libs/libqmi/Makefile +++ b/libs/libqmi/Makefile @@ -1,12 +1,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=libqmi -PKG_VERSION:=1.0 +PKG_VERSION:=1.8.0 PKG_RELEASE:=1 PKG_SOURCE:=libqmi-$(PKG_VERSION).tar.xz -PKG_SOURCE_URL:=@GNOME/libqmi/1.0/ -PKG_MD5SUM:=1e00d300616efc1bf8d3e8e541a69f73 +PKG_SOURCE_URL:=@GNOME/libqmi/1.8/ +PKG_MD5SUM:=1c4c64c0894f691632727363abec32b8 PKG_FIXUP:=autoreconf PKG_INSTALL:=1 There is no libqmi-1.8.0.tar.xz on the gnome ftp server. This url returns 404: http://ftp.gnome.org/pub/GNOME/sources/libqmi/1.8/libqmi-1.8.0.tar.xz Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] MyNET N750 - Actually turn the LNA on.
Very strange. I don't have the problem of the router being deaf anymore. However further investigation into the code leads me to believe that the value is never set to GPIOF_INIT_HIGH. Which is confusing. Or am I not seeing the obvious? ath79_wmac_set_ext_lna_gpio calls ar934x_set_ext_lna_gpio calls gpio_request_one and sets to GPIOF_DIR_OUT | GPIOF_INIT_LOW for the particular LNA GPIO. I reckon we need this to be GPIOF_INIT_HIGH in order for this to be in line with Felix's original patch. What bothers me is that if this patch isn't working, how is my device able to hear other devices just fine. I also agree with Felix, that value being passed in ath79_wmac_set_ext_lna_gpio as 0 or 1 is simply cosmetic, to produce an output of LNA0 or LNA1. It IS then later used to select AR934X_GPIO_OUT_EXT_LNA0 or AR934X_GPIO_OUT_EXT_LNA1 based on the provided value. I got lost in the ath79_gpio_output_select (maybe this is where the magic happens?) Best Regards, Chirag PS I own 2 N750s and they run in WDS AP and WDS AP+CLIENT mode and the devices see each other just fine. On Thu, Feb 6, 2014 at 5:37 PM, Luis E. Garcia l...@bitamins.net wrote: Images found here: http://openwrt.crc.id.au/ Steve The code you first sent was merged with revision 39213 for the N750. If I use your image with this patch ( the one marked ) r39211 - I can get connected with both radios. LuCI responds in a timely fashion. There is no lag when applying changes. They cleaned up the code in revision r39217, I couldn't find the definition for the function they're using ath79_wmac_set_ext_lna_gpio But all builds after that have issues with the radios, poor performance on the 5GHz radios - LuCI lags on the page that setups the WiFi radios. With the image you have as r39499 with the patch - the router behaves as with the r39213 with patch image. ( the first fix you sent ) I wanted to verify the state of the GPIOs on the kernel under the running linux system - that is why I asked if there was a way to verify the State of the GPIOs in your blog. Luis Garcia ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [packages] libftdi : fix build error
On 12/10/2013 07:17 PM, Dirk Neukirchen wrote: - using cmake to find libusb - fix header location fixes https://dev.openwrt.org/ticket/13258 Signed-off-by: Dirk Neukirchen dirkneukirc...@web.de Thank you for the patch, it was applied in r39519. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [packages] libftdi: fix pkgconfig support by installing .pc into staging dir
On 12/23/2013 04:07 PM, Alexander Couzens wrote: Signed-off-by: Alexander Couzens lyn...@fe80.eu --- libs/libftdi/Makefile | 2 ++ 1 file changed, 2 insertions(+) Thank you for the patch, it was applied in r39520. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] MyNET N750 - Actually turn the LNA on.
Chirag, Can you test the reception on the radios with the patch at r39213. Also can you check the behavior of LuCI with revision on the r394xx range. I get better reception on the 5GHz radio and a resposive LuCI [Configuration of radios WLan0 WLan1] with the changes made on patch r39213. Builds with revisons r39217 or later introduce lag on LuCI [Configuration of radios WLan0 WLan1] and the radio reception on the 5GHz is much lower in my tests. If you can point me in the right direction to check the state of the GPIOs from the console on the router I can test the images and see the status, and post back the results. Luis On Thu, Feb 6, 2014 at 4:46 PM, Chirag Chhatriwala cchha...@gmail.comwrote: Very strange. I don't have the problem of the router being deaf anymore. However further investigation into the code leads me to believe that the value is never set to GPIOF_INIT_HIGH. Which is confusing. Or am I not seeing the obvious? ath79_wmac_set_ext_lna_gpio calls ar934x_set_ext_lna_gpio calls gpio_request_one and sets to GPIOF_DIR_OUT | GPIOF_INIT_LOW for the particular LNA GPIO. I reckon we need this to be GPIOF_INIT_HIGH in order for this to be in line with Felix's original patch. What bothers me is that if this patch isn't working, how is my device able to hear other devices just fine. I also agree with Felix, that value being passed in ath79_wmac_set_ext_lna_gpio as 0 or 1 is simply cosmetic, to produce an output of LNA0 or LNA1. It IS then later used to select AR934X_GPIO_OUT_EXT_LNA0 or AR934X_GPIO_OUT_EXT_LNA1 based on the provided value. I got lost in the ath79_gpio_output_select (maybe this is where the magic happens?) Best Regards, Chirag PS I own 2 N750s and they run in WDS AP and WDS AP+CLIENT mode and the devices see each other just fine. On Thu, Feb 6, 2014 at 5:37 PM, Luis E. Garcia l...@bitamins.net wrote: Images found here: http://openwrt.crc.id.au/ Steve The code you first sent was merged with revision 39213 for the N750. If I use your image with this patch ( the one marked ) r39211 - I can get connected with both radios. LuCI responds in a timely fashion. There is no lag when applying changes. They cleaned up the code in revision r39217, I couldn't find the definition for the function they're using ath79_wmac_set_ext_lna_gpio But all builds after that have issues with the radios, poor performance on the 5GHz radios - LuCI lags on the page that setups the WiFi radios. With the image you have as r39499 with the patch - the router behaves as with the r39213 with patch image. ( the first fix you sent ) I wanted to verify the state of the GPIOs on the kernel under the running linux system - that is why I asked if there was a way to verify the State of the GPIOs in your blog. Luis Garcia ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [packages] taskwarrior: update to 2.20, fix compile
On 11/17/2013 11:27 PM, Dirk Neukirchen wrote: - fixes build errors (from buildbot logs): build/staging_dir/target-mips_34kc_uClibc-0.9.33.2/usr/lib/liblua.so: undefined reference to `dlsym' build/staging_dir/target-mips_34kc_uClibc-0.9.33.2/usr/lib/liblua.so: undefined reference to `dlerror' build/staging_dir/target-mips_34kc_uClibc-0.9.33.2/usr/lib/liblua.so: undefined reference to `dlopen' build/staging_dir/target-mips_34kc_uClibc-0.9.33.2/usr/lib/liblua.so: undefined reference to `dlclose' collect2: ld returned 1 exit status - depends on liblua, libuuid - use external libuuid instead of internal one - update to taskwarrior 2.2.0 Signed-off-by: Dirk Neukirchen dirkneukirc...@web.de --- utils/taskwarrior/Makefile | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) Thank you for the patch, it was applied in r39521. I also did an update to version 2.30 and add a libreadline dependency. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Lantiq DSL status info
Hi, does anyone know how to interact with the dsl daemon via a cli to query some extended data? I'd like to get a bit more data in the web interface and the dsl_control status call. Thanks! -- Marcus905 GPG pubkey: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x1FC0ECC932FE5FAC ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Firstboot problems
Hi, the router I'm working on at the moment, the DGN3500 lantiq platform, has a strange issue: it won't create or save the configuration. I see this in the logs: [0.00] Linux version 3.10.26 (marcus905@experiment) (gcc version 4.6.4 (OpenWrt/Linaro GCC 4.6-2013.05 r39286) ) #39 Thu Feb 6 19:19:14 CET 2014 [0.00] SoC: AR9 rev 1.1 [0.00] bootconsole [early0] enabled [0.00] CPU revision is: 0001954c (MIPS 34Kc) [0.00] MIPS: machine is DGN3500 - Netgear DGN3500 [0.00] Determined physical RAM map: [0.00] memory: 0400 @ (usable) [0.00] Initrd not found or empty - disabling initrd [0.00] Zone ranges: [0.00] Normal [mem 0x-0x03ff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x03ff] [0.00] On node 0 totalpages: 16384 [0.00] free_area_init_node: node 0, pgdat 8034e9d0, node_mem_map 81002a80 [0.00] Normal zone: 128 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 16384 pages, LIFO batch:3 [0.00] Primary instruction cache 32kB, VIPT, 4-way, linesize 32 bytes. [0.00] Primary data cache 16kB, 4-way, VIPT, no aliases, linesize 32 bytes [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 [0.00] Kernel command line: console=ttyLTQ0,115200 init=/etc/preinit ... [0.248000] squashfs: version 4.0 (2009/01/31) Phillip Lougher [0.256000] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc. ... [0.304000] spi_gpio spi.4: master is unqueued, this is deprecated [0.312000] m25p80 spi32766.0: found mx25l12805d, expected s25fl129p0 [0.316000] m25p80 spi32766.0: mx25l12805d (16384 Kbytes) [0.32] 4 ofpart partitions found on MTD device spi32766.0 [0.328000] Creating 4 MTD partitions on spi32766.0: [0.332000] 0x-0x0001 : uboot [0.34] 0x0001-0x0002 : uboot-env [0.348000] 0x0002-0x0003 : calibration [0.352000] 0x0005-0x00ff : firmware [0.36] 0x0017c7c8-0x00ff : rootfs [0.364000] mtd: partition rootfs must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only [0.38] mtd: device 4 (rootfs) set to be root filesystem [0.384000] mtd: partition rootfs_data created automatically, ofs=0x73, len=0x8c [0.392000] 0x0073-0x00ff : rootfs_data ... [ 160.68] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x: 0x7345 instead [ 160.696000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0004: 0x6f4d instead [ 160.712000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x000c: 0x5035 instead [ 160.728000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0010: 0x3600 instead [ 160.744000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x002c: 0x0041 instead [ 160.76] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0030: 0x3200 instead [ 160.776000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0038: 0x0011 instead [ 160.792000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0040: 0x4572 instead [ 160.808000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0044: 0x4d6d instead [ 160.824000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0048: 0x3845 instead [ 160.832000] jffs2: Further such events for this erase block will not be printed [ 160.948000] jffs2: Empty flash at 0x0050 ends at 0x1000 [ 161.072000] jffs2: Empty flash at 0x1004 ends at 0x2000 [ 163.168000] jffs2_scan_eraseblock(): End of filesystem marker found at 0x1 [ 163.176000] jffs2: Cowardly refusing to erase blocks on filesystem with no valid JFFS2 nodes [ 163.18] jffs2: empty_blocks 139, bad_blocks 0, c-nr_blocks 140 What could the problem be? What should I check? I think that it's creating rootfs_data in the correct place, but then the jffs2 filesystem starts looking for the end marker (deadc0de if i recall correctly) in the wrong place and therefore leaving the partition unformatted and leaving the config in the ramdisk. Any idea? -- Marcus905 GPG pubkey: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x1FC0ECC932FE5FAC ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] MyNET N750 - Actually turn the LNA on.
I'm copying Gabor so that he might help us. Chirag, I'm trying to read the status of the GPIOs by using the /sys/class/gpio/export root@OpenWrt:/# echo 15 /sys/class/gpio/export ash: write error: Device or resource busy This doesn’t work, as the system complains that resource is busy. I do have confirmation from another tester that the patch has now enabled the 5GHz radio on his N750 ( Check comment 25 26 on the following page: https://www.crc.id.au/2014/01/10/wd-mynet-n600-n750-openwrt-update/ ) Luis On Thu, Feb 6, 2014 at 4:59 PM, Luis E. Garcia l...@bitamins.net wrote: Chirag, Can you test the reception on the radios with the patch at r39213. Also can you check the behavior of LuCI with revision on the r394xx range. I get better reception on the 5GHz radio and a resposive LuCI [Configuration of radios WLan0 WLan1] with the changes made on patch r39213. Builds with revisons r39217 or later introduce lag on LuCI [Configuration of radios WLan0 WLan1] and the radio reception on the 5GHz is much lower in my tests. If you can point me in the right direction to check the state of the GPIOs from the console on the router I can test the images and see the status, and post back the results. Luis On Thu, Feb 6, 2014 at 4:46 PM, Chirag Chhatriwala cchha...@gmail.comwrote: Very strange. I don't have the problem of the router being deaf anymore. However further investigation into the code leads me to believe that the value is never set to GPIOF_INIT_HIGH. Which is confusing. Or am I not seeing the obvious? ath79_wmac_set_ext_lna_gpio calls ar934x_set_ext_lna_gpio calls gpio_request_one and sets to GPIOF_DIR_OUT | GPIOF_INIT_LOW for the particular LNA GPIO. I reckon we need this to be GPIOF_INIT_HIGH in order for this to be in line with Felix's original patch. What bothers me is that if this patch isn't working, how is my device able to hear other devices just fine. I also agree with Felix, that value being passed in ath79_wmac_set_ext_lna_gpio as 0 or 1 is simply cosmetic, to produce an output of LNA0 or LNA1. It IS then later used to select AR934X_GPIO_OUT_EXT_LNA0 or AR934X_GPIO_OUT_EXT_LNA1 based on the provided value. I got lost in the ath79_gpio_output_select (maybe this is where the magic happens?) Best Regards, Chirag PS I own 2 N750s and they run in WDS AP and WDS AP+CLIENT mode and the devices see each other just fine. On Thu, Feb 6, 2014 at 5:37 PM, Luis E. Garcia l...@bitamins.net wrote: Images found here: http://openwrt.crc.id.au/ Steve The code you first sent was merged with revision 39213 for the N750. If I use your image with this patch ( the one marked ) r39211 - I can get connected with both radios. LuCI responds in a timely fashion. There is no lag when applying changes. They cleaned up the code in revision r39217, I couldn't find the definition for the function they're using ath79_wmac_set_ext_lna_gpio But all builds after that have issues with the radios, poor performance on the 5GHz radios - LuCI lags on the page that setups the WiFi radios. With the image you have as r39499 with the patch - the router behaves as with the r39213 with patch image. ( the first fix you sent ) I wanted to verify the state of the GPIOs on the kernel under the running linux system - that is why I asked if there was a way to verify the State of the GPIOs in your blog. Luis Garcia ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
