Re: [OpenWrt-Devel] [PATCH 00/13] ramips: massive code cleanups
2015-07-30 14:24 GMT+02:00 John Crispin blo...@openwrt.org: [...] big diff stat. i like it. can you do the same for lantiq ? :) Maybe... and ar71xx too? ;) i will stop merging new board to ramips target untilt his series is in the tree to save you having to rebase too often. OK. when can we expect a v2 ? There was a discussion about upstream LED naming convention and this patch: [PATCH 05/13] ramips: use consistent naming scheme for LEDs, for various manufacturers I sent my idea about diag.sh and 01_leds scripts optimization, but it hasn't got any positive or negative feedback yet... so I decided to wait. I want to reorder my patches in v2 series (move other small changes in the front of that LED naming related stuff, so eventually they can be omitted without breaking other changes). I should be able to prepare v2 during the weekend. how do you create the patch ? i am a bit worried that cp bugs or similar can sneak in. In some cases by hand... in other, using available tools (sed, awk, grep, git grep etc.). My original series contained more than 30 patches (one change = one commit) and I verified every single one. I merged logically related commits into one change before sending whole series. I hope I didn't make more bugs than I'm trying to fix. Piotr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 00/13] ramips: massive code cleanups
On 26/07/2015 18:24, Piotr Dymacz wrote:
The following changes fix different mistakes in ramips target and
try to make the code more clean and consistent.
The patches affect:
* dts{,i} files
* base-files/* scripts
* image Makefile
Piotr Dymacz (13):
ramips: fix indentation and other mistakes in .dts{,i} files
ramips: remove leading spaces and sort boards alphabetically in
base-files/lib/ramips.sh
ramips: fix indentation, case statements structure and optimize
base-files/etc/board.d/* scripts
ramips: sort boards alphabetically and optimize
base-files/etc/{diag.sh,board.d/*} scripts
ramips: use consistent naming scheme for LEDs, for various
manufacturers
ramips: fix UPVEL model names
ramips: change board name for Zbtlink WR8305RT to ZBT-WR8305RT
ramips: remove unnecessary LED declaration for WT1520 in diag.sh
ramips: use consistent naming scheme for LEDs in the remaining,
branded devices
ramips: change board name for Asus WL-330N{,3G} to WL-330N{,3G}
ramips: rename dts file for Asus RT-N56U to RT-N56U.dts
ramips: be consistent with case statement in
base-files/lib/upgrade/platform.sh
ramips: fix image name for Belkin F7C027
big diff stat. i like it. can you do the same for lantiq ? :)
i will stop merging new board to ramips target untilt his series is in
the tree to save you having to rebase too often.
when can we expect a v2 ? how do you create the patch ? i am a bit
worried that cp bugs or similar can sneak in.
John
target/linux/ramips/base-files/etc/board.d/01_leds | 496
++---
.../linux/ramips/base-files/etc/board.d/02_network | 398 -
target/linux/ramips/base-files/etc/diag.sh | 207 +
target/linux/ramips/base-files/lib/ramips.sh | 288 ++--
.../ramips/base-files/lib/upgrade/platform.sh | 234 +-
target/linux/ramips/dts/ALL0239-3G.dts | 8 +-
target/linux/ramips/dts/ALL0256N-4M.dts| 6 +-
target/linux/ramips/dts/ALL0256N-8M.dts| 6 +-
target/linux/ramips/dts/AR670W.dts | 4 +-
target/linux/ramips/dts/AR725W.dts | 6 +-
target/linux/ramips/dts/ARGUS_ATP52B.dts | 4 +-
target/linux/ramips/dts/ASL26555-16M.dts | 16 +-
target/linux/ramips/dts/ASL26555-8M.dts| 16 +-
target/linux/ramips/dts/AWAPN2403.dts | 2 +-
target/linux/ramips/dts/AWM002-EVB-4M.dts | 6 +-
target/linux/ramips/dts/AWM002-EVB-8M.dts | 6 +-
target/linux/ramips/dts/AWM003-EVB.dts | 6 +-
target/linux/ramips/dts/BC2.dts| 2 +-
target/linux/ramips/dts/BROADWAY.dts | 4 +-
target/linux/ramips/dts/CF-WR800N.dts | 24 +-
target/linux/ramips/dts/D105.dts | 4 +-
target/linux/ramips/dts/DCS-930L-B1.dts| 2 +-
target/linux/ramips/dts/DIR-300-B7.dts | 65 ++-
target/linux/ramips/dts/DIR-320-B1.dts | 20 +-
target/linux/ramips/dts/DIR-610-A1.dts | 20 +-
target/linux/ramips/dts/ESR-9753.dts | 4 +-
target/linux/ramips/dts/F5D8235_V1.dts | 6 +-
target/linux/ramips/dts/F5D8235_V2.dts | 18 +-
target/linux/ramips/dts/FONERA20N.dts | 6 +-
target/linux/ramips/dts/FREESTATION5.dts | 6 +-
target/linux/ramips/dts/HG255D.dts | 12 +-
target/linux/ramips/dts/HLKRM04.dts| 2 +-
target/linux/ramips/dts/HT-TM02.dts| 4 +-
target/linux/ramips/dts/HW550-3G.dts | 8 +-
target/linux/ramips/dts/IP2202.dts | 4 +-
target/linux/ramips/dts/M2M.dts| 4 +-
target/linux/ramips/dts/M3.dts | 2 +-
target/linux/ramips/dts/M4-4M.dts | 2 +-
target/linux/ramips/dts/M4-8M.dts | 2 +-
target/linux/ramips/dts/MOFI3500-3GN.dts | 8 +-
target/linux/ramips/dts/MR-102N.dts| 6 +-
target/linux/ramips/dts/MZK-750DHP.dts | 4 +-
target/linux/ramips/dts/MZK-DP150N.dts | 2 +-
target/linux/ramips/dts/MZK-W300NH2.dts| 6 +-
target/linux/ramips/dts/MicroWRT.dts | 2 +-
target/linux/ramips/dts/NA930.dts | 8 +-
target/linux/ramips/dts/NBG-419N.dts | 4 +-
target/linux/ramips/dts/NCS601W.dts| 4 +-
target/linux/ramips/dts/NW718.dts | 6 +-
target/linux/ramips/dts/OLINUXINO-RT5350F-EVB.dts | 190
target/linux/ramips/dts/OLINUXINO-RT5350F.dts | 122 ++---
target/linux/ramips/dts/OMNI-EMB-HPM.dts | 12 +-
target/linux/ramips/dts/OMNI-EMB.dts | 4 +-
target/linux/ramips/dts/OMNI-PLUG.dts | 4 +-
target/linux/ramips/dts/OY-0001.dts
Re: [OpenWrt-Devel] [PATCH] rampips: Fix pinmux functions for MT7621
On 29/07/2015 17:19, Sven Eckelmann wrote:
The pinctrl-rt2880 code doesn't support multiple functions with the same
name. This will result in incorrect pinmux configuration.
The MT7621 uses 2 bit wide configuration of the sdhci, spi, mdio, pcie,
wdt, uart2 and uart3. But the code only changed a single bit for uart3,
uart2 and mdio. Also the order of uart2 and uart3 group was exchanged.
The spi nand settings was also reserved only 7 PINs instead of 8 as the
spi spi setting.
i stumbled across this problem on mt7628/88 last few days. the pinctrl
code was written for a core with 1 bit / function and then grew with new
socs. i'll try to fix this in the pinctrl driver the next few days
rather than have redundant function names.
John
Signed-off-by: Sven Eckelmann s...@open-mesh.com
---
target/linux/ramips/dts/mt7621.dtsi| 14 +++
.../0012-MIPS-ralink-add-MT7621-support.patch | 45
+++---
2 files changed, 38 insertions(+), 21 deletions(-)
diff --git a/target/linux/ramips/dts/mt7621.dtsi
b/target/linux/ramips/dts/mt7621.dtsi
index 53b215f40f10..f09ec3e5b694 100644
--- a/target/linux/ramips/dts/mt7621.dtsi
+++ b/target/linux/ramips/dts/mt7621.dtsi
@@ -130,31 +130,31 @@
uart1_pins: uart1 {
uart1 {
ralink,group = uart1;
- ralink,function = uart;
+ ralink,function = uart1;
};
};
uart2_pins: uart2 {
uart2 {
ralink,group = uart2;
- ralink,function = uart;
+ ralink,function = uart2;
};
};
uart3_pins: uart3 {
uart3 {
ralink,group = uart3;
- ralink,function = uart;
+ ralink,function = uart3;
};
};
rgmii1_pins: rgmii1 {
rgmii1 {
ralink,group = rgmii1;
- ralink,function = rgmii;
+ ralink,function = rgmii1;
};
};
rgmii2_pins: rgmii2 {
rgmii2 {
ralink,group = rgmii2;
- ralink,function = rgmii;
+ ralink,function = rgmii2;
};
};
mdio_pins: mdio {
@@ -172,11 +172,11 @@
nand_pins: nand {
spi-nand {
ralink,group = spi;
- ralink,function = nand;
+ ralink,function = nand1;
};
sdhci-nand {
ralink,group = sdhci;
- ralink,function = nand;
+ ralink,function = nand2;
};
};
sdhci_pins: sdhci {
diff --git
a/target/linux/ramips/patches-3.18/0012-MIPS-ralink-add-MT7621-support.patch
b/target/linux/ramips/patches-3.18/0012-MIPS-ralink-add-MT7621-support.patch
index 771de12f171d..23d32681bf77 100644
---
a/target/linux/ramips/patches-3.18/0012-MIPS-ralink-add-MT7621-support.patch
+++
b/target/linux/ramips/patches-3.18/0012-MIPS-ralink-add-MT7621-support.patch
@@ -520,7 +520,7 @@ Signed-off-by: John Crispin blo...@openwrt.org
+}
--- /dev/null
+++ b/arch/mips/ralink/mt7621.c
-@@ -0,0 +1,192 @@
+@@ -0,0 +1,209 @@
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
@@ -555,8 +555,12 @@ Signed-off-by: John Crispin blo...@openwrt.org
+
+#define MT7621_GPIO_MODE_UART1 1
+#define MT7621_GPIO_MODE_I2C2
-+#define MT7621_GPIO_MODE_UART2 3
-+#define MT7621_GPIO_MODE_UART3 5
++#define MT7621_GPIO_MODE_UART3_MASK 0x3
++#define MT7621_GPIO_MODE_UART3_SHIFT3
++#define MT7621_GPIO_MODE_UART3_GPIO 1
++#define MT7621_GPIO_MODE_UART2_MASK 0x3
++#define MT7621_GPIO_MODE_UART2_SHIFT5
++#define MT7621_GPIO_MODE_UART2_GPIO 1
+#define MT7621_GPIO_MODE_JTAG 7
+#define MT7621_GPIO_MODE_WDT_MASK 0x3
+#define MT7621_GPIO_MODE_WDT_SHIFT 8
@@ -566,7 +570,9 @@ Signed-off-by: John Crispin blo...@openwrt.org
+#define MT7621_GPIO_MODE_PCIE_MASK 0x3
+#define MT7621_GPIO_MODE_PCIE_SHIFT 10
+#define MT7621_GPIO_MODE_PCIE_GPIO 1
-+#define MT7621_GPIO_MODE_MDIO 12
++#define MT7621_GPIO_MODE_MDIO_MASK 0x3
++#define MT7621_GPIO_MODE_MDIO_SHIFT 12
++#define MT7621_GPIO_MODE_MDIO_GPIO 1
+#define
Re: [OpenWrt-Devel] RFC: Preserving smbpasswd dnsmasq.time across sysupgrade
Thanks Bastian, apologies for delayed reply. I'll check that info out. :-) Thanks Kevin -- Cheers, ke...@darbyshire-bryant.me.uk Sent from my phone, apologies for brevity, spelling top posting On 27 Jul 2015, at 09:14, Bastian Bittorf bitt...@bluebottle.com wrote: * Kevin Darbyshire-Bryant ke...@darbyshire-bryant.me.uk [26.07.2015 16:35]: The next question is how? It looks like a few other packages create a subdir in 'keep.d' with a file containing a list of files that should be preserved by default. I would anticipate creating 'samba' 'dnsmasq' subdirs though the package Makefiles. A better way? they should just be marked as 'conffiles' in the package itself andi these files are automatically choosen for including into sysupgrade.tgz the magic is done in add_uci_conffiles() line 100 in file package/base-files/files/sbin/sysupgrade - /sbin/sysupgrade bye, bastian smime.p7s Description: S/MIME cryptographic signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt] 2.4Ghz limited to 50mW in DFS-ETSI
You can look up your respective country's spectrum regulations. It is possible prior versions OpenWRT didn't fully conform to each regulatory domain and were fixed in more recent versions (just as the converse is possible). For example, for the USA, here is a table of power limits for the 2.4GHz and 5GHz bands. Channels 36-48 are limited to 16dBm transmitter power. http://www.air802.com/fcc-rules-and-regulations.html On Thu, Jul 30, 2015 at 3:32 AM, Nicola von Thadden n...@vthadden.de wrote: Hi, I also thought to have used 20dBm or 23dBm in earlier releases (AA). Is there a way to find out to which txpower levels the 5Ghz transceiver is limited? I think the driver reads them out, maybe there is a way to print them on the cmd? But my main problem is the 17dBm on 2.4Ghz when setting DFS-ETSI countries. I don't think that it is a problem of the hardware but of the software parsing the regdom. Maybe there is a fixed limit of 17dBm on non-DFS channels, even when DFS is not required, which is not very useful. Does anyone have an idea where that could be set? My search in the source code had no results until now, where it could be. Thanks Nico On 07/29/2015 06:21 PM, Atanas Vladimirov wrote: https://dev.openwrt.org/ticket/20201 On BB I used 20dBm for both 2.4 and 5GHz on the same router. Sent with AquaMail for Android http://www.aqua-mail.com On 29 юли 2015 г. 18:40:10 Ben West b...@gowasabi.net wrote: This is what I observe running Barrier Breaker on UBNT M5 products, too. I believe the 17dBm limit is intentional, i.e. per regulation. The 30dBm tx power limit applies to channels 149 and above, I believe. Also (kind of off-topic): Do you know why 5Ghz channels 36-48 are forced to be 17dBm only on the WNDR3800? I found two possible explanations: either because of the factory calibration On Wed, Jul 29, 2015 at 10:25 AM, Gerald Matzka mgeral...@yahoo.de mailto:mgeral...@yahoo.de wrote: Well, it looks like the txpower of your wdnr3800 is limited to 17dBm because of the hardware reg-domain settings. Kind regards, ... sent from my iPhone Am 29.07.2015 um 10:43 schrieb Nicola von Thadden n...@vthadden.de mailto:n...@vthadden.de: Hi, I have this strange behaviour down below, for which I also opened a ticket because I think this should not be like that ;) Does anyone have an idea where the problem could originate from and how to fix it? Thanks Nico On 07/29/2015 12:37 AM, OpenWrt wrote: #20222: 2.4Ghz limited to 50mW in DFS-ETSI --+-- Reporter: nicoduck | Owner: developers Type: defect| Status: new Priority: normal| Milestone: Chaos Calmer (trunk) Component: kernel|Version: Trunk Keywords: wndr3800 | --+-- I have got a Netgear WNDR 3800 running with openwrt since quite a while. I now upgraded to the latest version (trunk) and wanted to use WLAN within the regulations here in Germany but also wanted to max out the output power (within the regulations). Switching the country to Germany limits the maximum output power to 17dBm, although it does show as being limited on 20dBm: root@OpenWrt:/# iwinfo wlan0 txpower 0 dBm ( 1 mW) 1 dBm ( 1 mW) 2 dBm ( 1 mW) 3 dBm ( 1 mW) 4 dBm ( 2 mW) 5 dBm ( 3 mW) 6 dBm ( 3 mW) 7 dBm ( 5 mW) 8 dBm ( 6 mW) 9 dBm ( 7 mW) 10 dBm ( 10 mW) 11 dBm ( 12 mW) 12 dBm ( 15 mW) 13 dBm ( 19 mW) 14 dBm ( 25 mW) 15 dBm ( 31 mW) 16 dBm ( 39 mW) * 17 dBm ( 50 mW) 18 dBm ( 63 mW) 19 dBm ( 79 mW) 20 dBm ( 100 mW) What I did: reset the device, flash it with various builts from trunk and try to figure out what was going on. I now modified my regdb and was able to isolate the source of the problem: country DE: DFS-ETSI # entries 279004 and 280006 (2400 - 2483.5 @ 40), (100 mW) # entry 303005 (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW # entries 304002 and 305002 (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW # entries 308002, 309001 and 310003 (5470 - 5725 @ 160), (500 mW), DFS # 60 gHz band channels 1-4, ref: Etsi En 302 567 (57000 - 66000 @ 2160), (40) Thas does not work and has the mentioned behaviour, 2.4Ghz is limited at 17dBm. It also does not depend on which values are set in
Re: [OpenWrt-Devel] [PATCH] [brcm63xx] Add support for Plusnet 2704N
Hi, On Tue, Jul 28, 2015 at 6:28 AM, Matt Goring matt.gor...@googlemail.com wrote: BCM6318: add support for Plusnet / Sagem 2704N (V1) Signed-off-by: Matt Goring matt.gor...@googlemail.com --- For future submissions, add a changelog here for all the changes between (re-)submissions. target/linux/brcm63xx/base-files/etc/diag.sh |3 + .../brcm63xx/base-files/etc/uci-defaults/01_leds |3 + .../base-files/etc/uci-defaults/02_network |1 + target/linux/brcm63xx/base-files/lib/brcm63xx.sh |3 + target/linux/brcm63xx/dts/fast2704n.dts| 84 target/linux/brcm63xx/image/Makefile |2 + .../patches-3.18/571-board_fast2704n.patch | 65 +++ .../brcm63xx/patches-4.1/571-board_fast2704n.patch | 65 +++ target/linux/brcm63xx/profiles/sagem.mk| 10 +++ 9 files changed, 236 insertions(+) create mode 100644 target/linux/brcm63xx/dts/fast2704n.dts create mode 100644 target/linux/brcm63xx/patches-3.18/571-board_fast2704n.patch create mode 100644 target/linux/brcm63xx/patches-4.1/571-board_fast2704n.patch --- a/target/linux/brcm63xx/image/Makefile +++ b/target/linux/brcm63xx/image/Makefile @@ -623,6 +623,8 @@ $(eval $(call bcm63xxCfe,FAST2404,F@ST2404,fast2404,F@ST2404,6348)) $(eval $(call bcm63xxCfe,FAST2504n,F@ST2504n,fast2504n,F@ST2504n,6362)) # Sagem F@ST2604 $(eval $(call bcm63xxCfe,FAST2604,F@ST2604,fast2604,F@ST2604,6348)) +# Sagem F@ST2704N V1 / Plusnet F@ST2704N V1 +$(eval $(call bcm63xxCfe,FAST2704N,FAST2704N,fast2704n,F@ST2704N,6318,--pad 4)) I thought using F@ST2704N as the board name in the image does not work? Rest looks fine. Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lantiq: get more status information from xDSL
On Thu, Jul 30, 2015 at 10:35 AM, feckert eckert.flor...@googlemail.com wrote: Signed-off-by: Florian Eckert eckert.flor...@googlemail.com Signed-off-by: Helge Mader hma...@tdt.de Tested-by: Martin Blumenstingl martin.blumensti...@googlemail.com I only have two minor nitpicks: 1. Annex and Line Mode are ending with a comma (e.g. Annex: B, ) 2. I guess latency should be in milliseconds but it shows 800 / 550 here which seems a bit high (I am guessing that the correct values would be 8.0ms and 5.5ms - that's pure speculation though) The whole report is much more advanced now - I think we're now on par (except for some nice graphics in luci) with the DSL info that the usual vendor firmwares are showing, which is great! Regards, Martin ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [WDR3600] factory using WPS-button and tftp doesn't work anymore (new hardware?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Just in case anybody was following this; i've worked around the issue by prepending the first 257 blocks from an official firmware-upgrade and than padding to the required size (8192512). It seems that the automatic process now expects u-boot and and an ominous info-block to also be contained in the image. that might not be the proper solution. if anyone of you has a better idea - i'd like to hear it :-) kind regards On 29.07.2015 20:20, Leon George wrote: Hi :-) briefing: the automatic flashing-process - holding down the WPS-button in order to flash an image downloaded via TFTP - no longer works for certain WDR3600-devices with hardware revision 1.5 that have only minor (visible) differences to working devices with the same revision. .. this is going to be long - sorry for that. i'm trying to provide as many details as possible. I'm working on a factory-process for TP-Link WDR3600. Last week we have encountered an error where we were ( headache-english :-D ) not able to flash the last shipment using an automated process. There seems to be new hardware with the revision still being 1.5 but the u-boot behaving differently. From the outside, these devices look quite similar - the only differences we've found so far are: -there are four labels on the backside (as opposed to 3) the new one showing custom SSIDs (much like the one on the Archer-C5) -a label on the inside on the yellow LAN-ports has a string 4FC-1, which we have not seen yet - the working boards have 3FC-3 The only way to flash our image to this new hardware is to either: -flash manually using the u-boot-prompt (t ; e; cp.b; reset) -upload it to the firmware-update-page of the stock-firmware The images then boot and seem to be happy. That, however, is not acceptable for a factory-process.. Turns out that our image was 6815748 bytes in size (we forked from openwrt a while ago) which is not accepted by these new devices using the existing process. The router instantly resets after the firmware has been received (before hte flash is erased). Have a look at Flashing via TFTP in http://wiki.openwrt.org/toh/tp-link/tl-wdr4300 to see what we're doing - no magic involved :-) 'wrong_filesize.log' contains the serial-output when the file size is not 'correct'. So far, i've come to the conclusion that only files with size 8192512 / $7D0200 (bigger than the rootfs-mtd!) make it past the tftp download. I've tried padding the file with \x00 or \xFF. The file is then copied to the flash but will not boot. See 'successfull_flash.log' for the output. Notice the 'boot up image' after the transmission. You can see the error while booting at the end of that file (LZMA-length ). The last thing i've tried, is to use an image produces from OpenWRT-trunk - i gather you have introduced padding to the image since our fork. That image would also NOT be copied to the flash. Flashing does work if the file is padded to the 'magic' size but the boot-issue remains. I'm still working on this and will keep you informed - but if anyone of you has an idea on how to address this issue.. any help would be highly appreciated! The next thing on my TODO-list is to see how the image can be modified to make it boot. I'm comparing it to the firmware-upgrades from TP-Link (which do work using this process). But first: a good night's sleep :-p hoping this might help someone, kind regards, nice evenings to you, Leon M. George ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVuofgAAoJEPImwNGZR6nx1dMIANVEkO3ERaqLn9sPRUWxQrSo 5BN9locEKM43DbV0qFFLQOZdOGjyfhon2WQTnh1yLf/1uiM5YcmJNSQSg8Cmt9cG h0Z+JgMVCj7T++6VYMqfqChilN1NXo6UB27qLiC2PGlp0MiTJB/XQzUQHS77jzTR p0ihP2Ie82DsLXCBLB0UAMyG6eyqxvWnwlTgrq6AWN/8nKWWQBIESoGltW016qMT DRfQc8Z9vy/HMcPC9yBRRD3Vk4tzUZ+5Y+5sTum9eBEmEUaQJXzmJAmJ9nNzgzrY NUjzhNIrnmYmDu0HHaecXL/aDIb4ZyvqtBbQMwBROtK45z+ZpZV2I4F67pJ1O1Q= =/A24 -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt] 2.4Ghz limited to 50mW in DFS-ETSI
What's more, The regulation is on the signal strength of the radiated signal, not the transmitter power. so if you go to max transmitter power and add a better antenna, you actually exceed the limits. There is apparently an exception to this for point-to-point use. But you still can't use full power + high gain antenna David Lang On Thu, 30 Jul 2015, Ben West wrote: You can look up your respective country's spectrum regulations. It is possible prior versions OpenWRT didn't fully conform to each regulatory domain and were fixed in more recent versions (just as the converse is possible). For example, for the USA, here is a table of power limits for the 2.4GHz and 5GHz bands. Channels 36-48 are limited to 16dBm transmitter power. http://www.air802.com/fcc-rules-and-regulations.html On Thu, Jul 30, 2015 at 3:32 AM, Nicola von Thadden n...@vthadden.de wrote: Hi, I also thought to have used 20dBm or 23dBm in earlier releases (AA). Is there a way to find out to which txpower levels the 5Ghz transceiver is limited? I think the driver reads them out, maybe there is a way to print them on the cmd? But my main problem is the 17dBm on 2.4Ghz when setting DFS-ETSI countries. I don't think that it is a problem of the hardware but of the software parsing the regdom. Maybe there is a fixed limit of 17dBm on non-DFS channels, even when DFS is not required, which is not very useful. Does anyone have an idea where that could be set? My search in the source code had no results until now, where it could be. Thanks Nico On 07/29/2015 06:21 PM, Atanas Vladimirov wrote: https://dev.openwrt.org/ticket/20201 On BB I used 20dBm for both 2.4 and 5GHz on the same router. Sent with AquaMail for Android http://www.aqua-mail.com On 29 юли 2015 г. 18:40:10 Ben West b...@gowasabi.net wrote: This is what I observe running Barrier Breaker on UBNT M5 products, too. I believe the 17dBm limit is intentional, i.e. per regulation. The 30dBm tx power limit applies to channels 149 and above, I believe. Also (kind of off-topic): Do you know why 5Ghz channels 36-48 are forced to be 17dBm only on the WNDR3800? I found two possible explanations: either because of the factory calibration On Wed, Jul 29, 2015 at 10:25 AM, Gerald Matzka mgeral...@yahoo.de mailto:mgeral...@yahoo.de wrote: Well, it looks like the txpower of your wdnr3800 is limited to 17dBm because of the hardware reg-domain settings. Kind regards, ... sent from my iPhone Am 29.07.2015 um 10:43 schrieb Nicola von Thadden n...@vthadden.de mailto:n...@vthadden.de: Hi, I have this strange behaviour down below, for which I also opened a ticket because I think this should not be like that ;) Does anyone have an idea where the problem could originate from and how to fix it? Thanks Nico On 07/29/2015 12:37 AM, OpenWrt wrote: #20222: 2.4Ghz limited to 50mW in DFS-ETSI --+-- Reporter: nicoduck | Owner: developers Type: defect| Status: new Priority: normal| Milestone: Chaos Calmer (trunk) Component: kernel|Version: Trunk Keywords: wndr3800 | --+-- I have got a Netgear WNDR 3800 running with openwrt since quite a while. I now upgraded to the latest version (trunk) and wanted to use WLAN within the regulations here in Germany but also wanted to max out the output power (within the regulations). Switching the country to Germany limits the maximum output power to 17dBm, although it does show as being limited on 20dBm: root@OpenWrt:/# iwinfo wlan0 txpower 0 dBm ( 1 mW) 1 dBm ( 1 mW) 2 dBm ( 1 mW) 3 dBm ( 1 mW) 4 dBm ( 2 mW) 5 dBm ( 3 mW) 6 dBm ( 3 mW) 7 dBm ( 5 mW) 8 dBm ( 6 mW) 9 dBm ( 7 mW) 10 dBm ( 10 mW) 11 dBm ( 12 mW) 12 dBm ( 15 mW) 13 dBm ( 19 mW) 14 dBm ( 25 mW) 15 dBm ( 31 mW) 16 dBm ( 39 mW) * 17 dBm ( 50 mW) 18 dBm ( 63 mW) 19 dBm ( 79 mW) 20 dBm ( 100 mW) What I did: reset the device, flash it with various builts from trunk and try to figure out what was going on. I now modified my regdb and was able to isolate the source of the problem: country DE: DFS-ETSI # entries 279004 and 280006 (2400 - 2483.5 @ 40), (100 mW) # entry 303005 (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW # entries 304002 and 305002 (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW # entries 308002, 309001 and 310003 (5470 - 5725 @ 160), (500 mW), DFS # 60 gHz band channels 1-4, ref: Etsi En 302 567 (57000 - 66000 @ 2160), (40) Thas does not work and has the
Re: [OpenWrt-Devel] [PATCH 6/6] bcm53xx: R8000 handle PEX8603 switch
On 15 July 2015 at 12:11, Ian Kent ra...@themaw.net wrote: On Tue, 2015-07-14 at 18:19 +0200, Rafał Miłecki wrote: On 28 June 2015 at 05:37, Ian Kent ra...@themaw.net wrote: Let me rework this using the bus number as you recommend. I'll repost my updated patch series once I've done that. Hi Ian, Is there any chance you'll find a moment for it anytime soon? It'd be awesome to get R8000 support for CC release. I have reworked the patch and a broken package build problem I had is gone but I didn't get time to fix build problems with a third patch I have. Just didn't get time last weekend and this week has been quite busy too. I'll try and get onto this in the next few days. Ping, guys? :) Is this initial Ian's patch acceptable to pick it for CC release since we don't really seem to have time to improve it? -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2] dnsmasq: Bump to dnsmasq2.74
Bump to dnsmasq2.74 refresh patches to fix fuzz
Signed-off-by: Kevin Darbyshire-Bryant ke...@darbyshire-bryant.me.uk
---
v2 - fixed patch fuzz in 100-fix-dhcp-no-address-warning
package/network/services/dnsmasq/Makefile | 4 ++--
.../dnsmasq/patches/100-fix-dhcp-no-address-warning.patch | 6 +++---
.../patches/210-dnssec-improve-timestamp-heuristic.patch | 14 ++
3 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/package/network/services/dnsmasq/Makefile
b/package/network/services/dnsmasq/Makefile
index 19a8df9..9b0ecc5 100644
--- a/package/network/services/dnsmasq/Makefile
+++ b/package/network/services/dnsmasq/Makefile
@@ -8,12 +8,12 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=dnsmasq
-PKG_VERSION:=2.73
+PKG_VERSION:=2.74
PKG_RELEASE:=1
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
PKG_SOURCE_URL:=http://thekelleys.org.uk/dnsmasq
-PKG_MD5SUM:=b8bfe96d22945c8cf4466826ba9b21bd
+PKG_MD5SUM:=f48cd0fe26a55617a375ffc95b71e3c3
PKG_LICENSE:=GPL-2.0
PKG_LICENSE_FILES:=COPYING
diff --git
a/package/network/services/dnsmasq/patches/100-fix-dhcp-no-address-warning.patch
b/package/network/services/dnsmasq/patches/100-fix-dhcp-no-address-warning.patch
index a502a60..f5b5ca0 100644
---
a/package/network/services/dnsmasq/patches/100-fix-dhcp-no-address-warning.patch
+++
b/package/network/services/dnsmasq/patches/100-fix-dhcp-no-address-warning.patch
@@ -9,7 +9,7 @@
struct iface_param parm;
#ifdef HAVE_LINUX_NETWORK
struct arpreq arp_req;
-@@ -272,11 +272,9 @@ void dhcp_packet(time_t now, int pxe_fd)
+@@ -275,11 +275,9 @@ void dhcp_packet(time_t now, int pxe_fd)
{
ifr.ifr_addr.sa_family = AF_INET;
if (ioctl(daemon-dhcpfd, SIOCGIFADDR, ifr) != -1 )
@@ -23,7 +23,7 @@
}
for (tmp = daemon-dhcp_except; tmp; tmp = tmp-next)
-@@ -295,7 +293,7 @@ void dhcp_packet(time_t now, int pxe_fd)
+@@ -298,7 +296,7 @@ void dhcp_packet(time_t now, int pxe_fd)
parm.relay_local.s_addr = 0;
parm.ind = iface_index;
@@ -32,7 +32,7 @@
{
/* If we failed to match the primary address of the interface, see if
we've got a --listen-address
for a secondary */
-@@ -315,6 +313,12 @@ void dhcp_packet(time_t now, int pxe_fd)
+@@ -318,6 +316,12 @@ void dhcp_packet(time_t now, int pxe_fd)
complete_context(match.addr, iface_index, NULL, match.netmask,
match.broadcast, parm);
}
diff --git
a/package/network/services/dnsmasq/patches/210-dnssec-improve-timestamp-heuristic.patch
b/package/network/services/dnsmasq/patches/210-dnssec-improve-timestamp-heuristic.patch
index 97dfe3b..81fbf18 100644
---
a/package/network/services/dnsmasq/patches/210-dnssec-improve-timestamp-heuristic.patch
+++
b/package/network/services/dnsmasq/patches/210-dnssec-improve-timestamp-heuristic.patch
@@ -10,35 +10,33 @@ Signed-off-by: Steven Barth ste...@midlink.org
--- a/src/dnssec.c
+++ b/src/dnssec.c
-@@ -432,17 +432,24 @@ static int back_to_the_future;
+@@ -429,17 +429,24 @@ static time_t timestamp_time;
int setup_timestamp(void)
{
struct stat statbuf;
--
+ time_t now;
+ time_t base = 1420070400; /* 1-1-2015 */
-+
- back_to_the_future = 0;
+
+ daemon-back_to_the_future = 0;
if (!daemon-timestamp_file)
return 0;
--
+
+ now = time(NULL);
+
+ if (!stat(/proc/self/exe, statbuf) difftime(statbuf.st_mtime, base)
0)
+base = statbuf.st_mtime;
-+
+
if (stat(daemon-timestamp_file, statbuf) != -1)
{
timestamp_time = statbuf.st_mtime;
check_and_exit:
- if (difftime(timestamp_time, time(0)) = 0)
-+ if (difftime(now, base) = 0 difftime(timestamp_time, now) = 0)
++ if (difftime(now, base) = 0 difftime(timestamp_time, now) = 0)
{
/* time already OK, update timestamp, and do key checking from the
start. */
if (utime(daemon-timestamp_file, NULL) == -1)
-@@ -463,7 +470,7 @@ int setup_timestamp(void)
+@@ -460,7 +467,7 @@ int setup_timestamp(void)
close(fd);
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] OpenWRT default settings
Hi Everyone, I am working on openWRT Luci, able to change the settings in the file under overlay and settings will get change, but when i do factory reset from GUI, All the changes i have done in script file gone. So i need to know from which this all factory reset configuration is loading so that i will change it that file my default configuration. So that after factory reset it should with my default settings. Thanks, John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] lantiq: get more status information from xDSL
Signed-off-by: Florian Eckert eckert.flor...@googlemail.com
Signed-off-by: Helge Mader hma...@tdt.de
---
.../lantiq/base-files/lib/functions/lantiq_dsl.sh | 400 +++-
1 file changed, 388 insertions(+), 12 deletions(-)
mode change 100644 = 100755
target/linux/lantiq/base-files/lib/functions/lantiq_dsl.sh
diff --git a/target/linux/lantiq/base-files/lib/functions/lantiq_dsl.sh
b/target/linux/lantiq/base-files/lib/functions/lantiq_dsl.sh
old mode 100644
new mode 100755
index 56b8652..044bffa
--- a/target/linux/lantiq/base-files/lib/functions/lantiq_dsl.sh
+++ b/target/linux/lantiq/base-files/lib/functions/lantiq_dsl.sh
@@ -19,6 +19,9 @@ dsl_cmd() {
dsl_val() {
echo $(expr $1 : '.*'$2'=\([-\.[:alnum:]]*\).*')
}
+dsl_string() {
+ echo $(expr $1 : '.*'$2'=(\([A-Z0-9,]*\))')
+}
#
# Simple divide by 10 routine to cope with one decimal place
@@ -77,7 +80,7 @@ data_rates() {
echo dsl.data_rate_down_s=\$sdrd\
echo dsl.data_rate_up_s=\$sdru\
else
- echo Data Rate:${sdrd}/s / ${sdru}/s
+ echo Data Rate:Down: ${sdrd}/s
/ Up: ${sdru}/s
fi
}
@@ -92,11 +95,327 @@ chipset() {
vig=$(dsl_cmd vig)
cs=$(dsl_val $vig DSL_ChipSetType)
csv=$(dsl_val $vig DSL_ChipSetHWVersion)
+ csfw=$(dsl_val $vig DSL_ChipSetFWVersion)
+ csapi=$(dsl_val $vig DSL_DriverVersionApi)
if [ $action = lucistat ]; then
echo dsl.chipset=\${cs} ${csv}\
+ echo dsl.firmware_version=\${csfw}\
+ echo dsl.api_version=\${csapi}\
+ else
+ echo Chipset: ${cs} ${csv}
+ echo Firmware Version: ${csfw}
+ echo API Version: ${csapi}
+ fi
+}
+
+#
+# Vendor information
+#
+vendor() {
+ local lig
+ local vid
+ local svid
+
+ lig=$(dsl_cmd g997lig 1)
+ vid=$(dsl_string $lig G994VendorID)
+ svid=$(dsl_string $lig SystemVendorID)
+
+ if [ $action = lucistat ]; then
+ echo dsl.atuc_vendor_id=\${vid}\
+ echo dsl.atuc_system_vendor_id=\${svid}\
+ else
+ echo ATU-C Vendor ID: ${vid}
+ echo ATU-C System Vendor ID: ${svid}
+ fi
+}
+
+#
+# XTSE capabilities
+#
+xtse() {
+ local xtusesg
+ local xtse1
+ local xtse2
+ local xtse3
+ local xtse4
+ local xtse5
+ local xtse6
+ local xtse7
+ local xtse8
+
+ local xtse_s=
+
+ local annex_s=
+ local line_mode_s=
+
+ xtusesg=$(dsl_cmd g997xtusesg)
+ xtse1=$(dsl_val $xtusesg XTSE1)
+ xtse2=$(dsl_val $xtusesg XTSE2)
+ xtse3=$(dsl_val $xtusesg XTSE3)
+ xtse4=$(dsl_val $xtusesg XTSE4)
+ xtse5=$(dsl_val $xtusesg XTSE5)
+ xtse6=$(dsl_val $xtusesg XTSE6)
+ xtse7=$(dsl_val $xtusesg XTSE7)
+ xtse8=$(dsl_val $xtusesg XTSE8)
+
+ # Evaluate Annex (according to G.997.1, 7.3.1.1.1)
+ if [ $((xtse1 13)) != 0 \
+ -o $((xtse2 1)) != 0 \
+ -o $((xtse3 12)) != 0 \
+ -o $((xtse4 3)) != 0 \
+ -o $((xtse6 3)) != 0 \
+ -o $((xtse8 1)) != 0 ]; then
+ annex_s= A,
+ fi
+
+ if [ $((xtse1 48)) != 0 \
+ -o $((xtse2 2)) != 0 \
+ -o $((xtse3 48)) != 0 \
+ -o $((xtse6 12)) != 0 \
+ -o $((xtse8 2)) != 0 ]; then
+ annex_s=$annex_s B,
+ fi
+
+ if [ $((xtse1 194)) != 0 \
+ -o $((xtse2 12)) != 0 \
+ -o $((xtse8 4)) != 0 ]; then
+ annex_s=$annex_s C,
+ fi
+
+ if [ $((xtse4 48)) != 0 \
+ -o $((xtse5 3)) != 0 \
+ -o $((xtse6 192)) != 0 ]; then
+ annex_s=$annex_s I,
+ fi
+
+ if [ $((xtse4 192)) != 0 \
+ -o $((xtse7 3)) != 0 ]; then
+ annex_s=$annex_s J,
+ fi
+
+ if [ $((xtse5 60)) != 0 ]; then
+ annex_s=$annex_s L,
+ fi
+
+ if [ $((xtse5 192)) != 0 \
+ -o $((xtse7 12)) != 0 ]; then
+ annex_s=$annex_s M,
+ fi
+
+
+ # Evaluate Line Mode (according to G.997.1, 7.3.1.1.1)
+
+ # Regional standard: ANSI T1.413
+ if [ $((xtse1 1)) != 0 ]; then
+ line_mode_s= T1.413,
+ fi
+
+ # Regional standard: TS 101 388
+ if [ $((xtse1 1)) != 0 ]; then
+ line_mode_s=$line_mode_s TS 101 388,
+ fi
+
+ if [ $((xtse1 252)) != 0 ]; then
+ line_mode_s=$line_mode_s G.992.1 (ADSL),
+ fi
+
+ if [ $((xtse2 15)) != 0 ]; then
+ line_mode_s=$line_mode_s G.992.2 (ADSL lite),
+ fi
+
+ if [ $((xtse3 60)) != 0 \
+ -o $((xtse4 240)) != 0 \
+ -o $((xtse5 252)) != 0 ]; then
+
Re: [OpenWrt-Devel] [OpenWrt] 2.4Ghz limited to 50mW in DFS-ETSI
Hi, I also thought to have used 20dBm or 23dBm in earlier releases (AA). Is there a way to find out to which txpower levels the 5Ghz transceiver is limited? I think the driver reads them out, maybe there is a way to print them on the cmd? But my main problem is the 17dBm on 2.4Ghz when setting DFS-ETSI countries. I don't think that it is a problem of the hardware but of the software parsing the regdom. Maybe there is a fixed limit of 17dBm on non-DFS channels, even when DFS is not required, which is not very useful. Does anyone have an idea where that could be set? My search in the source code had no results until now, where it could be. Thanks Nico On 07/29/2015 06:21 PM, Atanas Vladimirov wrote: https://dev.openwrt.org/ticket/20201 On BB I used 20dBm for both 2.4 and 5GHz on the same router. Sent with AquaMail for Android http://www.aqua-mail.com On 29 юли 2015 г. 18:40:10 Ben West b...@gowasabi.net wrote: This is what I observe running Barrier Breaker on UBNT M5 products, too. I believe the 17dBm limit is intentional, i.e. per regulation. The 30dBm tx power limit applies to channels 149 and above, I believe. Also (kind of off-topic): Do you know why 5Ghz channels 36-48 are forced to be 17dBm only on the WNDR3800? I found two possible explanations: either because of the factory calibration On Wed, Jul 29, 2015 at 10:25 AM, Gerald Matzka mgeral...@yahoo.de mailto:mgeral...@yahoo.de wrote: Well, it looks like the txpower of your wdnr3800 is limited to 17dBm because of the hardware reg-domain settings. Kind regards, ... sent from my iPhone Am 29.07.2015 um 10:43 schrieb Nicola von Thadden n...@vthadden.de mailto:n...@vthadden.de: Hi, I have this strange behaviour down below, for which I also opened a ticket because I think this should not be like that ;) Does anyone have an idea where the problem could originate from and how to fix it? Thanks Nico On 07/29/2015 12:37 AM, OpenWrt wrote: #20222: 2.4Ghz limited to 50mW in DFS-ETSI --+-- Reporter: nicoduck | Owner: developers Type: defect| Status: new Priority: normal| Milestone: Chaos Calmer (trunk) Component: kernel|Version: Trunk Keywords: wndr3800 | --+-- I have got a Netgear WNDR 3800 running with openwrt since quite a while. I now upgraded to the latest version (trunk) and wanted to use WLAN within the regulations here in Germany but also wanted to max out the output power (within the regulations). Switching the country to Germany limits the maximum output power to 17dBm, although it does show as being limited on 20dBm: root@OpenWrt:/# iwinfo wlan0 txpower 0 dBm ( 1 mW) 1 dBm ( 1 mW) 2 dBm ( 1 mW) 3 dBm ( 1 mW) 4 dBm ( 2 mW) 5 dBm ( 3 mW) 6 dBm ( 3 mW) 7 dBm ( 5 mW) 8 dBm ( 6 mW) 9 dBm ( 7 mW) 10 dBm ( 10 mW) 11 dBm ( 12 mW) 12 dBm ( 15 mW) 13 dBm ( 19 mW) 14 dBm ( 25 mW) 15 dBm ( 31 mW) 16 dBm ( 39 mW) * 17 dBm ( 50 mW) 18 dBm ( 63 mW) 19 dBm ( 79 mW) 20 dBm ( 100 mW) What I did: reset the device, flash it with various builts from trunk and try to figure out what was going on. I now modified my regdb and was able to isolate the source of the problem: country DE: DFS-ETSI # entries 279004 and 280006 (2400 - 2483.5 @ 40), (100 mW) # entry 303005 (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW # entries 304002 and 305002 (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW # entries 308002, 309001 and 310003 (5470 - 5725 @ 160), (500 mW), DFS # 60 gHz band channels 1-4, ref: Etsi En 302 567 (57000 - 66000 @ 2160), (40) Thas does not work and has the mentioned behaviour, 2.4Ghz is limited at 17dBm. It also does not depend on which values are set in the regulatory database for the 2.4Ghz channels, anything over 17dBm will be limited to 17dBm. running iw phy phy0 set txpower fixed 2000 gives no error but does not change it to 20dBm. Changing the value to anything below 17dBm works though. country DE: DFS-FCC # entries 279004 and 280006 (2400 - 2483.5 @ 40), (100 mW) # entry 303005 (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW # entries 304002 and 305002 (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW
[OpenWrt-Devel] [PATCH] update config.guess config.sub
These are from today's master branch of:
http://git.savannah.gnu.org/gitweb/?p=config.git;a=tree
In particular it adds support for ARC architecture plus some more
improvements and fixes.
This patch is built-tested against NetGear WNDR3800.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Cc: Florian Fainelli flor...@openwrt.org
Cc: Imre Kaloz ka...@openwrt.org
---
scripts/config.guess | 378 +++
scripts/config.sub | 150
2 files changed, 238 insertions(+), 290 deletions(-)
diff --git a/scripts/config.guess b/scripts/config.guess
index d622a44..fddac42 100755
--- a/scripts/config.guess
+++ b/scripts/config.guess
@@ -1,14 +1,12 @@
#! /bin/sh
# Attempt to guess a canonical system name.
-# Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-# 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010,
-# 2011, 2012 Free Software Foundation, Inc.
+# Copyright 1992-2015 Free Software Foundation, Inc.
-timestamp='2012-02-10'
+timestamp='2015-07-03'
# This file is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 2 of the License, or
+# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful, but
@@ -22,19 +20,17 @@ timestamp='2012-02-10'
# As a special exception to the GNU General Public License, if you
# distribute this file as part of a program that contains a
# configuration script generated by Autoconf, you may include it under
-# the same distribution terms that you use for the rest of that program.
-
-
-# Originally written by Per Bothner. Please send patches (context
-# diff format) to config-patc...@gnu.org and include a ChangeLog
-# entry.
+# the same distribution terms that you use for the rest of that
+# program. This Exception is an additional permission under section 7
+# of the GNU General Public License, version 3 (GPLv3).
#
-# This script attempts to guess a canonical system name similar to
-# config.sub. If it succeeds, it prints the system name on stdout, and
-# exits with 0. Otherwise, it exits with 1.
+# Originally written by Per Bothner; maintained since 2000 by Ben Elliston.
#
# You can get the latest version of this script from:
#
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
+#
+# Please send patches to config-patc...@gnu.org.
+
me=`echo $0 | sed -e 's,.*/,,'`
@@ -54,9 +50,7 @@ version=\
GNU config.guess ($timestamp)
Originally written by Per Bothner.
-Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000,
-2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012
-Free Software Foundation, Inc.
+Copyright 1992-2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
@@ -138,6 +132,27 @@ UNAME_RELEASE=`(uname -r) 2/dev/null` ||
UNAME_RELEASE=unknown
UNAME_SYSTEM=`(uname -s) 2/dev/null` || UNAME_SYSTEM=unknown
UNAME_VERSION=`(uname -v) 2/dev/null` || UNAME_VERSION=unknown
+case ${UNAME_SYSTEM} in
+Linux|GNU|GNU/*)
+ # If the system lacks a compiler, then just pick glibc.
+ # We could probably try harder.
+ LIBC=gnu
+
+ eval $set_cc_for_build
+ cat -EOF $dummy.c
+ #include features.h
+ #if defined(__UCLIBC__)
+ LIBC=uclibc
+ #elif defined(__dietlibc__)
+ LIBC=dietlibc
+ #else
+ LIBC=gnu
+ #endif
+ EOF
+ eval `$CC_FOR_BUILD -E $dummy.c 2/dev/null | grep '^LIBC' | sed 's,
,,g'`
+ ;;
+esac
+
# Note: order is significant - the case branches are not exclusive.
case ${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION} in
@@ -153,20 +168,27 @@ case
${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION} in
# Note: NetBSD doesn't particularly care about the vendor
# portion of the name. We always set it to unknown.
sysctl=sysctl -n hw.machine_arch
- UNAME_MACHINE_ARCH=`(/sbin/$sysctl 2/dev/null || \
- /usr/sbin/$sysctl 2/dev/null || echo unknown)`
+ UNAME_MACHINE_ARCH=`(uname -p 2/dev/null || \
+ /sbin/$sysctl 2/dev/null || \
+ /usr/sbin/$sysctl 2/dev/null || \
+ echo unknown)`
case ${UNAME_MACHINE_ARCH} in
armeb) machine=armeb-unknown ;;
arm*) machine=arm-unknown ;;
sh3el) machine=shl-unknown ;;
sh3eb) machine=sh-unknown ;;
sh5el) machine=sh5le-unknown ;;
+ earmv*)
+ arch=`echo ${UNAME_MACHINE_ARCH} | sed -e
's,^e\(armv[0-9]\).*$,\1,'`
+ endian=`echo ${UNAME_MACHINE_ARCH} | sed -ne
's,^.*\(eb\)$,\1,p'`
+
[OpenWrt-Devel] [PATCH] include/kernel.mk - better search for ARCH
If findstring is used without leading and trailing spaces unexpected matches may happen. For example consider ARC=arc then findstring $(ARCH) will report a false match with aarch64. But findstring $ARCH (note trailing space) will correctly skip matches for both aarch64 and aarch64_be. This patch is built-tested against NetGear WNDR3800. Signed-off-by: Alexey Brodkin abrod...@synopsys.com Cc: Felix Fietkau n...@openwrt.org Cc: Jo-Philipp Wich j...@openwrt.org --- include/kernel.mk | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/include/kernel.mk b/include/kernel.mk index 7a0a170..95909fd 100644 --- a/include/kernel.mk +++ b/include/kernel.mk @@ -62,15 +62,15 @@ endif ifneq (,$(findstring uml,$(BOARD))) LINUX_KARCH=um -else ifneq (,$(findstring $(ARCH), aarch64 aarch64_be)) +else ifneq (, $(findstring $(ARCH) , aarch64 aarch64_be )) LINUX_KARCH := arm64 -else ifneq (,$(findstring $(ARCH), armeb)) +else ifneq (, $(findstring $(ARCH) , armeb )) LINUX_KARCH := arm -else ifneq (,$(findstring $(ARCH), mipsel mips64 mips64el)) +else ifneq (, $(findstring $(ARCH) , mipsel mips64 mips64el )) LINUX_KARCH := mips -else ifneq (,$(findstring $(ARCH), sh2 sh3 sh4)) +else ifneq (, $(findstring $(ARCH) , sh2 sh3 sh4 )) LINUX_KARCH := sh -else ifneq (,$(findstring $(ARCH), i386 x86_64)) +else ifneq (, $(findstring $(ARCH) , i386 x86_64 )) LINUX_KARCH := x86 else LINUX_KARCH := $(ARCH) -- 2.4.3 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCHv2 5/7] mac80211/linux-firmware: include firmware for brcmfmac-sdio
Signed-off-by: Daniel Golle dan...@makrotopia.org --- package/kernel/mac80211/Makefile | 48 ++-- 1 file changed, 46 insertions(+), 2 deletions(-) diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile index 40b08c0..4052acd 100644 --- a/package/kernel/mac80211/Makefile +++ b/package/kernel/mac80211/Makefile @@ -108,8 +108,8 @@ Generic IEEE 802.11 Networking Stack (mac80211) endef PKG_LINUX_FIRMWARE_NAME:=linux-firmware -PKG_LINUX_FIRMWARE_VERSION:=f404336ba808cbd57547196e13367079a23b822c -PKG_LINUX_FIRMWARE_SOURCE:=$(PKG_LINUX_FIRMWARE_NAME)-2015-03-20-$(PKG_LINUX_FIRMWARE_VERSION).tar.bz2 +PKG_LINUX_FIRMWARE_VERSION:=75cc3ef8ba6712fd72c073b17a790282136cc743 +PKG_LINUX_FIRMWARE_SOURCE:=$(PKG_LINUX_FIRMWARE_NAME)-2015-07-22-$(PKG_LINUX_FIRMWARE_VERSION).tar.bz2 PKG_LINUX_FIRMWARE_PROTO:=git PKG_LINUX_FIRMWARE_SOURCE_URL:=https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git PKG_LINUX_FIRMWARE_SUBDIR:=$(PKG_LINUX_FIRMWARE_NAME)-$(PKG_LINUX_FIRMWARE_VERSION) @@ -2000,6 +2000,50 @@ endef define KernelPackage/brcmfmac/install $(INSTALL_DIR) $(1)/lib/firmware/brcm +ifneq ($(CONFIG_BRCMFMAC_SDIO),) + $(INSTALL_DATA) \ + $(PKG_BUILD_DIR)/$(PKG_LINUX_FIRMWARE_SUBDIR)/brcm/brcmfmac43143-sdio.bin \ + $(1)/lib/firmware/brcm/ + $(INSTALL_DATA) \ + $(PKG_BUILD_DIR)/$(PKG_LINUX_FIRMWARE_SUBDIR)/brcm/brcmfmac43241b0-sdio.bin \ + $(1)/lib/firmware/brcm/ + $(INSTALL_DATA) \ + $(PKG_BUILD_DIR)/$(PKG_LINUX_FIRMWARE_SUBDIR)/brcm/brcmfmac43241b4-sdio.bin \ + $(1)/lib/firmware/brcm/ + $(INSTALL_DATA) \ + $(PKG_BUILD_DIR)/$(PKG_LINUX_FIRMWARE_SUBDIR)/brcm/brcmfmac43241b5-sdio.bin \ + $(1)/lib/firmware/brcm/ + $(INSTALL_DATA) \ + $(PKG_BUILD_DIR)/$(PKG_LINUX_FIRMWARE_SUBDIR)/brcm/brcmfmac4329-sdio.bin \ + $(1)/lib/firmware/brcm/ + $(INSTALL_DATA) \ + $(PKG_BUILD_DIR)/$(PKG_LINUX_FIRMWARE_SUBDIR)/brcm/brcmfmac4330-sdio.bin \ + $(1)/lib/firmware/brcm/ + $(INSTALL_DATA) \ + $(PKG_BUILD_DIR)/$(PKG_LINUX_FIRMWARE_SUBDIR)/brcm/brcmfmac4334-sdio.bin \ + $(1)/lib/firmware/brcm/ + $(INSTALL_DATA) \ + $(PKG_BUILD_DIR)/$(PKG_LINUX_FIRMWARE_SUBDIR)/brcm/brcmfmac4334-sdio.bin \ + $(1)/lib/firmware/brcm/ + $(INSTALL_DATA) \ + $(PKG_BUILD_DIR)/$(PKG_LINUX_FIRMWARE_SUBDIR)/brcm/brcmfmac43340-sdio.bin \ + $(1)/lib/firmware/brcm/ + $(INSTALL_DATA) \ + $(PKG_BUILD_DIR)/$(PKG_LINUX_FIRMWARE_SUBDIR)/brcm/brcmfmac43362-sdio.bin \ + $(1)/lib/firmware/brcm/ + $(INSTALL_DATA) \ + $(PKG_BUILD_DIR)/$(PKG_LINUX_FIRMWARE_SUBDIR)/brcm/brcmfmac4339-sdio.bin \ + $(1)/lib/firmware/brcm/ + $(INSTALL_DATA) \ + $(PKG_BUILD_DIR)/$(PKG_LINUX_FIRMWARE_SUBDIR)/brcm/brcmfmac43430-sdio.bin \ + $(1)/lib/firmware/brcm/ + $(INSTALL_DATA) \ + $(PKG_BUILD_DIR)/$(PKG_LINUX_FIRMWARE_SUBDIR)/brcm/brcmfmac43435-sdio.bin \ + $(1)/lib/firmware/brcm/ + $(INSTALL_DATA) \ + $(PKG_BUILD_DIR)/$(PKG_LINUX_FIRMWARE_SUBDIR)/brcm/brcmfmac4354-sdio.bin \ + $(1)/lib/firmware/brcm/ +endef ifneq ($(CONFIG_BRCMFMAC_USB),) $(INSTALL_DATA) \ $(PKG_BUILD_DIR)/$(PKG_LINUX_FIRMWARE_SUBDIR)/brcm/brcmfmac43236b.bin \ -- 2.4.6 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] AR71xx openWRT Default config file
Hi , I am working on openWRT Luci, able to change the settings in the file under overlay and settings will get change, but when i do factory reset from GUI, All the changes i have done in script file gone. So i need to know from which this all factory reset configuration is loading so that i will change it that file my default configuration. So that after factory reset it should with my default settings. Thanks, John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ar71xx: Fix gpio_count setting for QCA953x in ath79_gpio_output_select
Reported-by: Steve Brown sbr...@cortland.com
Signed-off-by: Sven Eckelmann s...@open-mesh.com
---
.../739-MIPS-ath79-add-gpio-func-register-for-QCA955x-SoC.patch | 2 +-
.../739-MIPS-ath79-add-gpio-func-register-for-QCA955x-SoC.patch | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
a/target/linux/ar71xx/patches-3.18/739-MIPS-ath79-add-gpio-func-register-for-QCA955x-SoC.patch
b/target/linux/ar71xx/patches-3.18/739-MIPS-ath79-add-gpio-func-register-for-QCA955x-SoC.patch
index af828b04bffd..24ce7d83c56d 100644
---
a/target/linux/ar71xx/patches-3.18/739-MIPS-ath79-add-gpio-func-register-for-QCA955x-SoC.patch
+++
b/target/linux/ar71xx/patches-3.18/739-MIPS-ath79-add-gpio-func-register-for-QCA955x-SoC.patch
@@ -14,7 +14,7 @@
+ gpio_count = AR934X_GPIO_COUNT;
+ reg_base = AR934X_GPIO_REG_OUT_FUNC0;
+ } else if (soc_is_qca953x()) {
-+ reg_base = QCA953X_GPIO_COUNT;
++ gpio_count = QCA953X_GPIO_COUNT;
+ reg_base = QCA953X_GPIO_REG_OUT_FUNC0;
+ } else if (soc_is_qca955x()) {
+ gpio_count = QCA955X_GPIO_COUNT;
diff --git
a/target/linux/ar71xx/patches-4.1/739-MIPS-ath79-add-gpio-func-register-for-QCA955x-SoC.patch
b/target/linux/ar71xx/patches-4.1/739-MIPS-ath79-add-gpio-func-register-for-QCA955x-SoC.patch
index af828b04bffd..24ce7d83c56d 100644
---
a/target/linux/ar71xx/patches-4.1/739-MIPS-ath79-add-gpio-func-register-for-QCA955x-SoC.patch
+++
b/target/linux/ar71xx/patches-4.1/739-MIPS-ath79-add-gpio-func-register-for-QCA955x-SoC.patch
@@ -14,7 +14,7 @@
+ gpio_count = AR934X_GPIO_COUNT;
+ reg_base = AR934X_GPIO_REG_OUT_FUNC0;
+ } else if (soc_is_qca953x()) {
-+ reg_base = QCA953X_GPIO_COUNT;
++ gpio_count = QCA953X_GPIO_COUNT;
+ reg_base = QCA953X_GPIO_REG_OUT_FUNC0;
+ } else if (soc_is_qca955x()) {
+ gpio_count = QCA955X_GPIO_COUNT;
--
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 5/7] linux-firmware: use newer upstream, package brcmfmac-firmware
On Thu, Jul 30, 2015 at 05:55:02AM +0200, Rafał Miłecki wrote: On 30 July 2015 at 03:52, Daniel Golle dan...@makrotopia.org wrote: Add new brcmfmac-firmware package. (Firmware blobs for BCM43362 were added upstream recently) PKG_MIRROR_MD5SUM should be re-added once the newer file is available on OpenWrt's mirror. You need to describe it better. What's the point of this if we already have KernelPackage/brcmfmac ? KernelPackage/brcmfmac contains the cfg80211 driver which needs binary firmware blobs to be present in /lib/firmware/brcm/ The blobs needed for BCM43362 were only recently added to linux-firmware, thus the version bump is needed as well. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt] 2.4Ghz limited to 50mW in DFS-ETSI
Ben is right, take a look at https://forum.openwrt.org/viewtopic.php?id=42197 In newer Openwrt versions the kernel modules are compiled to respect the reg-domain settings programmed in hardware. Kind regards ... sent from my iPhone Am 30.07.2015 um 17:11 schrieb Ben West b...@gowasabi.net: You can look up your respective country's spectrum regulations. It is possible prior versions OpenWRT didn't fully conform to each regulatory domain and were fixed in more recent versions (just as the converse is possible). For example, for the USA, here is a table of power limits for the 2.4GHz and 5GHz bands. Channels 36-48 are limited to 16dBm transmitter power. http://www.air802.com/fcc-rules-and-regulations.html On Thu, Jul 30, 2015 at 3:32 AM, Nicola von Thadden n...@vthadden.de wrote: Hi, I also thought to have used 20dBm or 23dBm in earlier releases (AA). Is there a way to find out to which txpower levels the 5Ghz transceiver is limited? I think the driver reads them out, maybe there is a way to print them on the cmd? But my main problem is the 17dBm on 2.4Ghz when setting DFS-ETSI countries. I don't think that it is a problem of the hardware but of the software parsing the regdom. Maybe there is a fixed limit of 17dBm on non-DFS channels, even when DFS is not required, which is not very useful. Does anyone have an idea where that could be set? My search in the source code had no results until now, where it could be. Thanks Nico On 07/29/2015 06:21 PM, Atanas Vladimirov wrote: https://dev.openwrt.org/ticket/20201 On BB I used 20dBm for both 2.4 and 5GHz on the same router. Sent with AquaMail for Android http://www.aqua-mail.com On 29 юли 2015 г. 18:40:10 Ben West b...@gowasabi.net wrote: This is what I observe running Barrier Breaker on UBNT M5 products, too. I believe the 17dBm limit is intentional, i.e. per regulation. The 30dBm tx power limit applies to channels 149 and above, I believe. Also (kind of off-topic): Do you know why 5Ghz channels 36-48 are forced to be 17dBm only on the WNDR3800? I found two possible explanations: either because of the factory calibration On Wed, Jul 29, 2015 at 10:25 AM, Gerald Matzka mgeral...@yahoo.de mailto:mgeral...@yahoo.de wrote: Well, it looks like the txpower of your wdnr3800 is limited to 17dBm because of the hardware reg-domain settings. Kind regards, ... sent from my iPhone Am 29.07.2015 um 10:43 schrieb Nicola von Thadden n...@vthadden.de mailto:n...@vthadden.de: Hi, I have this strange behaviour down below, for which I also opened a ticket because I think this should not be like that ;) Does anyone have an idea where the problem could originate from and how to fix it? Thanks Nico On 07/29/2015 12:37 AM, OpenWrt wrote: #20222: 2.4Ghz limited to 50mW in DFS-ETSI --+-- Reporter: nicoduck | Owner: developers Type: defect| Status: new Priority: normal| Milestone: Chaos Calmer (trunk) Component: kernel|Version: Trunk Keywords: wndr3800 | --+-- I have got a Netgear WNDR 3800 running with openwrt since quite a while. I now upgraded to the latest version (trunk) and wanted to use WLAN within the regulations here in Germany but also wanted to max out the output power (within the regulations). Switching the country to Germany limits the maximum output power to 17dBm, although it does show as being limited on 20dBm: root@OpenWrt:/# iwinfo wlan0 txpower 0 dBm ( 1 mW) 1 dBm ( 1 mW) 2 dBm ( 1 mW) 3 dBm ( 1 mW) 4 dBm ( 2 mW) 5 dBm ( 3 mW) 6 dBm ( 3 mW) 7 dBm ( 5 mW) 8 dBm ( 6 mW) 9 dBm ( 7 mW) 10 dBm ( 10 mW) 11 dBm ( 12 mW) 12 dBm ( 15 mW) 13 dBm ( 19 mW) 14 dBm ( 25 mW) 15 dBm ( 31 mW) 16 dBm ( 39 mW) * 17 dBm ( 50 mW) 18 dBm ( 63 mW) 19 dBm ( 79 mW) 20 dBm ( 100 mW) What I did: reset the device, flash it with various builts from trunk and try to figure out what was going on. I now modified my regdb and was able to isolate the source of the problem: country DE: DFS-ETSI # entries 279004 and 280006 (2400 - 2483.5 @ 40), (100 mW) # entry 303005 (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW # entries 304002 and 305002 (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW # entries 308002, 309001 and
[OpenWrt-Devel] how to control PA in mt7620a ralink-soc?
Dear Sir, I have something to trouble you , I want to know how to enable the PA of the mt7620a ralink-soc in the OpenWrt-BB ,and is there any article or mail has been explained ,but I don't know ? Please share it to me , I am eager to get help , thank you very much !!! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] include/kernel.mk - better search for ARCH
On 2015-07-30 10:41, Alexey Brodkin wrote: If findstring is used without leading and trailing spaces unexpected matches may happen. For example consider ARC=arc then findstring $(ARCH) will report a false match with aarch64. But findstring $ARCH (note trailing space) will correctly skip matches for both aarch64 and aarch64_be. This patch is built-tested against NetGear WNDR3800. Signed-off-by: Alexey Brodkin abrod...@synopsys.com Cc: Felix Fietkau n...@openwrt.org Cc: Jo-Philipp Wich j...@openwrt.org --- include/kernel.mk | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/include/kernel.mk b/include/kernel.mk index 7a0a170..95909fd 100644 --- a/include/kernel.mk +++ b/include/kernel.mk @@ -62,15 +62,15 @@ endif ifneq (,$(findstring uml,$(BOARD))) LINUX_KARCH=um -else ifneq (,$(findstring $(ARCH), aarch64 aarch64_be)) +else ifneq (, $(findstring $(ARCH) , aarch64 aarch64_be )) LINUX_KARCH := arm64 -else ifneq (,$(findstring $(ARCH), armeb)) +else ifneq (, $(findstring $(ARCH) , armeb )) LINUX_KARCH := arm -else ifneq (,$(findstring $(ARCH), mipsel mips64 mips64el)) +else ifneq (, $(findstring $(ARCH) , mipsel mips64 mips64el )) LINUX_KARCH := mips -else ifneq (,$(findstring $(ARCH), sh2 sh3 sh4)) +else ifneq (, $(findstring $(ARCH) , sh2 sh3 sh4 )) LINUX_KARCH := sh -else ifneq (,$(findstring $(ARCH), i386 x86_64)) +else ifneq (, $(findstring $(ARCH) , i386 x86_64 )) Why did you add the leading whitespace before $(findstring...)? - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] include/kernel.mk - better search for ARCH
Hi Felix, On Thu, 2015-07-30 at 12:55 +0200, Felix Fietkau wrote: On 2015-07-30 10:41, Alexey Brodkin wrote: If findstring is used without leading and trailing spaces unexpected matches may happen. For example consider ARC=arc then findstring $(ARCH) will report a false match with aarch64. But findstring $ARCH (note trailing space) will correctly skip matches for both aarch64 and aarch64_be. This patch is built-tested against NetGear WNDR3800. Signed-off-by: Alexey Brodkin abrod...@synopsys.com Cc: Felix Fietkau n...@openwrt.org Cc: Jo-Philipp Wich j...@openwrt.org --- include/kernel.mk | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/include/kernel.mk b/include/kernel.mk index 7a0a170..95909fd 100644 --- a/include/kernel.mk +++ b/include/kernel.mk @@ -62,15 +62,15 @@ endif ifneq (,$(findstring uml,$(BOARD))) LINUX_KARCH=um -else ifneq (,$(findstring $(ARCH), aarch64 aarch64_be)) +else ifneq (, $(findstring $(ARCH) , aarch64 aarch64_be )) LINUX_KARCH := arm64 -else ifneq (,$(findstring $(ARCH), armeb)) +else ifneq (, $(findstring $(ARCH) , armeb )) LINUX_KARCH := arm -else ifneq (,$(findstring $(ARCH), mipsel mips64 mips64el)) +else ifneq (, $(findstring $(ARCH) , mipsel mips64 mips64el )) LINUX_KARCH := mips -else ifneq (,$(findstring $(ARCH), sh2 sh3 sh4)) +else ifneq (, $(findstring $(ARCH) , sh2 sh3 sh4 )) LINUX_KARCH := sh -else ifneq (,$(findstring $(ARCH), i386 x86_64)) +else ifneq (, $(findstring $(ARCH) , i386 x86_64 )) Why did you add the leading whitespace before $(findstring...)? Indeed this is not necessary because this is definitely out of scope of findstring. If there're no more comments I'll send v2 soon. -Alexey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCHv2 6/7] ap6210-nvram: new package
This package contains the WiFi NVRAM distributed with Bananian. It's currently needed to use the WiFi module (BCM43362 SDIO) on the BananaPro with the brcmfmac cfg80211 driver. Signed-off-by: Daniel Golle dan...@makrotopia.org --- package/firmware/ap6210-nvram/Makefile | 40 +++ .../firmware/ap6210-nvram/files/nvram_ap6210.txt | 57 ++ 2 files changed, 97 insertions(+) create mode 100644 package/firmware/ap6210-nvram/Makefile create mode 100644 package/firmware/ap6210-nvram/files/nvram_ap6210.txt diff --git a/package/firmware/ap6210-nvram/Makefile b/package/firmware/ap6210-nvram/Makefile new file mode 100644 index 000..dec302e --- /dev/null +++ b/package/firmware/ap6210-nvram/Makefile @@ -0,0 +1,40 @@ +# +# Copyright (C) 2015 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:=ap6210-nvram +PKG_VERSION:=1.2-20130319 +PKG_RELEASE:=1 + +include $(INCLUDE_DIR)/package.mk + +define Package/ap6210-nvram + SECTION:=firmware + CATEGORY:=Firmware + TITLE:=NVRAM for the Ampak AP6210 Broadcom SDIO WiFi module + DEPENDS:=kmod-brcmfmac +endef + +define Package/ap6210-nvram/description + This package contains the WiFi NVRAM distributed with Bananian. + It's currently needed to use the WiFi module (BCM43362 SDIO) on the + BananaPro with the brcmfmac cfg80211 driver. +endef + +define Build/Prepare +endef + +define Build/Compile +endef + +define Package/ap6210-nvram/install + $(INSTALL_DIR) $(1)/lib/firmware/brcm + $(INSTALL_BIN) ./files/nvram_ap6210.txt $(1)/lib/firmware/brcm/brcmfmac43362-sdio.txt +endef + +$(eval $(call BuildPackage,ap6210-nvram)) diff --git a/package/firmware/ap6210-nvram/files/nvram_ap6210.txt b/package/firmware/ap6210-nvram/files/nvram_ap6210.txt new file mode 100644 index 000..4aa4287 --- /dev/null +++ b/package/firmware/ap6210-nvram/files/nvram_ap6210.txt @@ -0,0 +1,57 @@ +#AP6210_NVRAM_V1.2_03192013 +manfid=0x2d0 +prodid=0x492 +vendid=0x14e4 +devid=0x4343 +boardtype=0x0598 + +# Board Revision is P307, same nvram file can be used for P304, P305, P306 and P307 as the tssi pa params used are same +#Please force the automatic RX PER data to the respective board directory if not using P307 board, for e.g. for P305 boards force the data into the following directory /projects/BCM43362/a1_labdata/boardtests/results/sdg_rev0305 +boardrev=0x1307 +boardnum=777 +xtalfreq=26000 +boardflags=0x80201 +boardflags2=0x80 +sromrev=3 +wl0id=0x431b +macaddr=00:90:4c:07:71:12 +aa2g=1 +ag0=2 +maxp2ga0=74 +cck2gpo=0x +ofdm2gpo=0x +mcs2gpo0=0x +mcs2gpo1=0x +pa0maxpwr=56 + +#P207 PA params +#pa0b0=5447 +#pa0b1=-658 +#pa0b2=-175div/div + +#Same PA params for P304,P305, P306, P307 + +pa0b0=5447 +pa0b1=-607 +pa0b2=-160 +pa0itssit=62 +pa1itssit=62 + + +cckPwrOffset=5 +ccode=0 +rssismf2g=0xa +rssismc2g=0x3 +rssisav2g=0x7 +triso2g=0 +noise_cal_enable_2g=0 +noise_cal_po_2g=0 +swctrlmap_2g=0x04040404,0x02020202,0x02020202,0x010101,0x1ff +temp_add=29767 +temp_mult=425 + +btc_flags=0x6 +btc_params0=5000 +btc_params1=1000 +btc_params6=63 + -- 2.4.6 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
