[OpenWrt-Devel] [PATCH v2] ipq40xx: add support for ASUS Lyra

[Marius Genheimer]

SoC:   Qualcomm IPQ4019 (Dakota) 717 MHz, 4 cores
RAM:   256 MiB (Nanya NT5CC128M16IP-DI)
FLASH: 128 MiB (Macronix NAND)
WiFi0: Qualcomm IPQ4019 b/g/n 2x2
WiFi1: Qualcomm IPQ4019 a/n/ac 2x2
WiFi2: Qualcomm Atheros QCA9886 a/n/ac
BT:Atheros AR3012
IN:WPS Button, Reset Button
OUT:   RGB-LED via TI LP5523 9-channel Controller
UART:  Front of Device - 115200 N-8
   Pinout 3.3v - RX - TX - GND (Square is VCC)

Installation:
1. Transfer OpenWRT-initramfs image to the device via SSH to /tmp.
Login credentials are identical to the Web UI.

2. Login to the device via SSH.

3. Flash the initramfs image using

> mtd-write -d linux -i openwrt-image-file

4. Power-cycle the device and wait for OpenWRT to boot.

5. From there flash the OpenWRT-sysupgrade image.

Ethernet-Ports: Although labeled identically, the port next to
the power socket is the LAN port and the other one is WAN. This
is the same behavior as in the stock firmware.

Signed-off-by: Marius Genheimer 
---
 package/firmware/ipq-wifi/Makefile |   3 +-
 package/firmware/ipq-wifi/board-map-ac2200.bin | Bin 0 -> 24324 bytes
 .../ipq40xx/base-files/etc/board.d/02_network  |   8 +
 .../etc/hotplug.d/firmware/11-ath10k-caldata   |   9 +
 .../lib/preinit/05_set_iface_mac_ipq40xx.sh|   5 +
 .../ipq40xx/base-files/lib/upgrade/platform.sh |   4 +
 target/linux/ipq40xx/config-4.14   |   1 +
 .../arch/arm/boot/dts/qcom-ipq4019-map-ac2200.dts  | 304 +
 .../arch/arm/boot/dts/qcom-ipq4019-map-ac2200.dts  | 304 +
 target/linux/ipq40xx/image/Makefile|   9 +
 .../patches-4.14/901-arm-boot-add-dts-files.patch  |   3 +-
 .../patches-4.19/901-arm-boot-add-dts-files.patch  |   3 +-
 12 files changed, 650 insertions(+), 3 deletions(-)
 create mode 100644 package/firmware/ipq-wifi/board-map-ac2200.bin
 create mode 100644 
target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-map-ac2200.dts
 create mode 100644 
target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-map-ac2200.dts

diff --git a/package/firmware/ipq-wifi/Makefile 
b/package/firmware/ipq-wifi/Makefile
index cf1ad042bf..7c9def8967 100644
--- a/package/firmware/ipq-wifi/Makefile
+++ b/package/firmware/ipq-wifi/Makefile
@@ -17,7 +17,7 @@ endef
 # Please send a mail with your device-specific board files upstream.
 # You can find instructions and examples on the linux-wireless wiki:
 # 
-ALLWIFIBOARDS:=engenius_eap1300 linksys_ea6350v3
+ALLWIFIBOARDS:=asus_map-ac2200 engenius_eap1300 linksys_ea6350v3
 ALLWIFIPACKAGES:=$(foreach BOARD,$(ALLWIFIBOARDS),ipq-wifi-$(BOARD))
 
 define Package/ipq-wifi-default
@@ -52,6 +52,7 @@ Don't install it for any other device!
 endef
 
 #$(eval $(call 
generate-ipq-wifi-package,,,))
+$(eval $(call 
generate-ipq-wifi-package,asus_map-ac2200,board-map-ac2200.bin,ASUS MAP-AC2200))
 $(eval $(call 
generate-ipq-wifi-package,engenius_eap1300,board-engenius_eap1300.bin,EnGenius 
EAP1300))
 $(eval $(call 
generate-ipq-wifi-package,linksys_ea6350v3,board-linksys_ea6350v3.bin,Linksys 
EA6350v3))
 
diff --git a/package/firmware/ipq-wifi/board-map-ac2200.bin 
b/package/firmware/ipq-wifi/board-map-ac2200.bin
new file mode 100644
index 
..372936010a4723ee0197dc56cbfd3a193e559552
GIT binary patch
literal 24324
zcmeHPeNak-f$|Vq#_}SHh=UL>2J)qF*bY=ny#pH1~^Bu7H`L7>iDn%Zh=dF6z`3y}w9AY!C+OCE1C;w!|6
z4#_g)hDOlH9Z#fVlE+kc4tui2_PEy_7?-$Wlan`;i4|
zZ}OE7T_~=LD-@{$l%I81zq|RUxO~kkAN5wXY}abidr3|5tGrb24I`b!htrBf
zvwRhoE~=YT>ep2T6b@akJQsN=sKh(($wG;amO{XT_0;mGS7P2it5yfB38KF7EjjTW
zYZ1!JDu){)xV>O7nM?+8c60Oa@K|CN*4JH)2l76DYm1O05b)t&2roF8@9vfY>3
zdrx9D8eNzZ0*#H8mD{!{lci|+@+C{iuB4(6K93g!1rF;!zl@LjfJWK~;~GyE)7|}l
zrlt%b)D!(Va{B;C=+UFFDlEMHCt%TdG*(h^@X+D68%|!Jl;#NqMaPmdFrmoIa_s>M8)u8zci5Oe
z?l1ONdf{G}AD)OOiWBc7Vrh7qI87-dF%0AP!I_;YnjjSUR3APFKd@F=H`U93Cf*Q<|=a
zc}0-dCWu(t?GHYiP$L1G)0tSiC2t%0CZ~`_Wwtg~xF@COV9(X3QKC_r
z0Rehx%m9p)c~PQdg#cZk5ug#E5ug#E5ug!R#0adCtipoWFG^m-HnZ1D)?@MPrIet|
zf~E@tBa_djXKja1)5my<5~q!^h%X^Mbyq>aPS%2}?j$I873v4?A_VyXeaGP4sX4r<
zhIiC>;A#$^~`egSK#NJP=cSekO%@InP;0wqOu$5a7286v~eGDFeHyf
zNYBO?z95a}{FFHtF2#@x$=u}#L%$ml)gly)_!vT5Al~qR~{*b_ZOUna6dzlTKR
zrsU<0Ay%yiw+rg;efb^w>Z|WeIiVAY7S~1Ke!nM&$=nS)5C}1t?n~bVIS)e3_$tU;
zY|0(*<=Qd$#Y}lvXoz4w6S;Fo?$wdIbIL8-cI?XAU8rw7)!f$6+11xSc=h@xpMG)I
z@e1VdE$fr!fK2Fv
z{ZyX^mN^^_A`=+<=HgiG$^*K`7VR<~(Gk!cFTy$+_vn_1)rI>)UUMa#~B<
zhQE_?+jcEwZEG7HZR_y#wC2Q6wT|bDayyrvv^@)D0itA2*v@H#=@8lqU(gkPOmyjw
z3{$FuyzW~DIv`-8o<1h({eg+@UUfrbGIzA{x;u*B=z%aFHxHI`LZEx05ug!RbO`L&
zk(ohq?0^3G$A3=d*b}__|9BGYtSsb`}_a++n>Jw{;yzL2{*eI|DS#u`=0cd
z$zr3(KF7!Z{R3%pCa|`6_mPoeF_FX(;o)nAz`4hrqlK?qYwC`RJ4dsHgDu{@g>FB=
zeV=%HbB%f^vrBojyn8AXm!ZGU+l1_SheED}$!AlzY8*6lXf}Y54GO3{Bc1RiczjI9$IK7KTjC
zG}>%!_UK2(HhqO=t7^URBmEgoS`0f&>?*C~e^x57kd^qR3E?(~gkY-YjK>WX`aB59U^t>L)vAmi7|v;mQWB(*qaPbD=`rT(OY
zD3q8(li{F#k2V7;+w})DTU3z{NQ<^Yl`a*HUNN54muWVq2ndHyZixV;4~JU}<@#K$

Re: [OpenWrt-Devel] [PATCH v2] ipq40xx: add support for ASUS Lyra

[Christian Lamparter]

On Tuesday, February 12, 2019 5:19:51 PM CET Marius Genheimer wrote:
> SoC:   Qualcomm IPQ4019 (Dakota) 717 MHz, 4 cores
> RAM:   256 MiB (Nanya NT5CC128M16IP-DI)
> FLASH: 128 MiB (Macronix NAND)
> WiFi0: Qualcomm IPQ4019 b/g/n 2x2
> WiFi1: Qualcomm IPQ4019 a/n/ac 2x2
> WiFi2: Qualcomm Atheros QCA9886 a/n/ac
> BT:Atheros AR3012
> IN:WPS Button, Reset Button
> OUT:   RGB-LED via TI LP5523 9-channel Controller
> UART:  Front of Device - 115200 N-8
>Pinout 3.3v - RX - TX - GND (Square is VCC)
> 
> Installation:
> 1. Transfer OpenWRT-initramfs image to the device via SSH to /tmp.
> Login credentials are identical to the Web UI.
> 
> 2. Login to the device via SSH.
> 
> 3. Flash the initramfs image using
> 
> > mtd-write -d linux -i openwrt-image-file
> 
> 4. Power-cycle the device and wait for OpenWRT to boot.
> 
> 5. From there flash the OpenWRT-sysupgrade image.
> 
> Ethernet-Ports: Although labeled identically, the port next to
> the power socket is the LAN port and the other one is WAN. This
> is the same behavior as in the stock firmware.
> 
> Signed-off-by: Marius Genheimer 
> ---
Thanks. I made some changes to the commit, please let me know 
if the QCA9886 still works as expected (I copied the board WA
from ath79 for the time being - but it would be nice to have
the boardData for the QCA9886 upstream as well - see below).

https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=0be33481fbb784958476cd3449a0c3bd306ac535

> +{
> + status = "okay";
> + qcom,ath10k-calibration-variant = "ASUS-MAP-AC2200";
> +};
> +
> +{
> + status = "okay";
> + qcom,ath10k-calibration-variant = "ASUS-MAP-AC2200";
> +};
> +
> + {
> + status = "okay";
> + perst-gpio = < 38 GPIO_ACTIVE_LOW>;
> + wake-gpio = < 50 GPIO_ACTIVE_LOW>;
> +
> + bridge@0,0 {
> + reg = <0x 0 0 0 0>;
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges;
> +
> + wifi2: wifi@1,0 {
> + compatible = "qcom,ath10k";
> + status = "okay";
> + reg = <0x0001 0 0 0 0>;
> + qcom,ath10k-calibration-variant = "ASUS-MAP-AC2200";
> + };
> + };
> +};
> +
Since you added the "qcom,ath10k-calibration-variant" for the QCA9886, I looked
into the stock firmware and compared the custom boardData with what's upstream
in the ath10k-firmware board-2.bin repositories. And indeed, you probably want
to also upstream the boardData of the QCA9886(variant of the QCA9888). 

The process is the same as with the IPQ4019/QCA4019 boardData:


Best Regards,
Christian



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] apm821xx, ath79, lantiq, ramips: move named gpio exports to generic

[Daniel Golle]

The patch was copied to a bunch of platforms and seems to be a quite
useful feature for various things. Move it to generic to avoid code
duplication.

Signed-off-by: Daniel Golle 
---
 .../140-GPIO-add-named-gpio-exports.patch | 169 --
 .../500-GPIO-add-named-gpio-exports.patch}|   0
 .../500-GPIO-add-named-gpio-exports.patch}|   0
 .../0030-GPIO-add-named-gpio-exports.patch| 169 --
 .../0024-GPIO-add-named-gpio-exports.patch| 165 -
 5 files changed, 503 deletions(-)
 delete mode 100644 
target/linux/apm821xx/patches-4.14/140-GPIO-add-named-gpio-exports.patch
 rename target/linux/{ath79/patches-4.14/0036-GPIO-add-named-gpio-exports.patch 
=> generic/hack-4.14/500-GPIO-add-named-gpio-exports.patch} (100%)
 rename 
target/linux/{apm821xx/patches-4.19/140-GPIO-add-named-gpio-exports.patch => 
generic/hack-4.19/500-GPIO-add-named-gpio-exports.patch} (100%)
 delete mode 100644 
target/linux/lantiq/patches-4.14/0030-GPIO-add-named-gpio-exports.patch
 delete mode 100644 
target/linux/ramips/patches-4.14/0024-GPIO-add-named-gpio-exports.patch

diff --git 
a/target/linux/apm821xx/patches-4.14/140-GPIO-add-named-gpio-exports.patch 
b/target/linux/apm821xx/patches-4.14/140-GPIO-add-named-gpio-exports.patch
deleted file mode 100644
index fe4ea4fc24..00
--- a/target/linux/apm821xx/patches-4.14/140-GPIO-add-named-gpio-exports.patch
+++ /dev/null
@@ -1,169 +0,0 @@
-From cc809a441d8f2924f785eb863dfa6aef47a25b0b Mon Sep 17 00:00:00 2001
-From: John Crispin 
-Date: Tue, 12 Aug 2014 20:49:27 +0200
-Subject: [PATCH 30/36] GPIO: add named gpio exports
-
-Signed-off-by: John Crispin 

- drivers/gpio/gpiolib-of.c |   68 +
- drivers/gpio/gpiolib.c|   11 +--
- include/asm-generic/gpio.h|5 +++
- include/linux/gpio/consumer.h |8 +
- 4 files changed, 90 insertions(+), 2 deletions(-)
-
 a/drivers/gpio/gpiolib-of.c
-+++ b/drivers/gpio/gpiolib-of.c
-@@ -23,6 +23,8 @@
- #include 
- #include 
- #include 
-+#include 
-+#include 
- 
- #include "gpiolib.h"
- 
-@@ -507,3 +509,72 @@ void of_gpiochip_remove(struct gpio_chip
-   gpiochip_remove_pin_ranges(chip);
-   of_node_put(chip->of_node);
- }
-+
-+#ifdef CONFIG_GPIO_SYSFS
-+
-+static struct of_device_id gpio_export_ids[] = {
-+  { .compatible = "gpio-export" },
-+  { /* sentinel */ }
-+};
-+
-+static int of_gpio_export_probe(struct platform_device *pdev)
-+{
-+  struct device_node *np = pdev->dev.of_node;
-+  struct device_node *cnp;
-+  u32 val;
-+  int nb = 0;
-+
-+  for_each_child_of_node(np, cnp) {
-+  const char *name = NULL;
-+  int gpio;
-+  bool dmc;
-+  int max_gpio = 1;
-+  int i;
-+
-+  of_property_read_string(cnp, "gpio-export,name", );
-+
-+  if (!name)
-+  max_gpio = of_gpio_count(cnp);
-+
-+  for (i = 0; i < max_gpio; i++) {
-+  unsigned flags = 0;
-+  enum of_gpio_flags of_flags;
-+
-+  gpio = of_get_gpio_flags(cnp, i, _flags);
-+  if (!gpio_is_valid(gpio))
-+  return gpio;
-+
-+  if (of_flags == OF_GPIO_ACTIVE_LOW)
-+  flags |= GPIOF_ACTIVE_LOW;
-+
-+  if (!of_property_read_u32(cnp, "gpio-export,output", 
))
-+  flags |= val ? GPIOF_OUT_INIT_HIGH : 
GPIOF_OUT_INIT_LOW;
-+  else
-+  flags |= GPIOF_IN;
-+
-+  if (devm_gpio_request_one(>dev, gpio, flags, name 
? name : of_node_full_name(np)))
-+  continue;
-+
-+  dmc = of_property_read_bool(cnp, 
"gpio-export,direction_may_change");
-+  gpio_export_with_name(gpio, dmc, name);
-+  nb++;
-+  }
-+  }
-+
-+  dev_info(>dev, "%d gpio(s) exported\n", nb);
-+
-+  return 0;
-+}
-+
-+static struct platform_driver gpio_export_driver = {
-+  .driver = {
-+  .name   = "gpio-export",
-+  .owner  = THIS_MODULE,
-+  .of_match_table = of_match_ptr(gpio_export_ids),
-+  },
-+  .probe  = of_gpio_export_probe,
-+};
-+
-+module_platform_driver(gpio_export_driver);
-+
-+#endif
 a/include/asm-generic/gpio.h
-+++ b/include/asm-generic/gpio.h
-@@ -127,6 +127,12 @@ static inline int gpio_export(unsigned g
-   return gpiod_export(gpio_to_desc(gpio), direction_may_change);
- }
- 
-+int __gpiod_export(struct gpio_desc *desc, bool direction_may_change, const 
char *name);
-+static inline int gpio_export_with_name(unsigned gpio, bool 
direction_may_change, const char *name)
-+{
-+  return __gpiod_export(gpio_to_desc(gpio), direction_may_change, name);
-+}
-+
- static inline int 

Re: [OpenWrt-Devel] [PATCH 3/3] ipq40xx: add support for FritzBox 7530

[David Bauer]

Hi Christian,

On 11.02.19 23:15, Christian Lamparter wrote:
> Comments inline.
> 
> On Sunday, February 10, 2019 2:34:30 PM CET David Bauer wrote:
>> Hardware
>> 
>> CPU:   Qualcomm IPQ4019
>> RAM:   256M
>> FLASH: 128M NAND
>> ETH:   QCA8075
>> VDSL:  Intel/Lantiq VRX518 PCIe attached
>>currently not supported
> 
> Does the pcie device show up during boot when
> you add and enable the pcie nodes in the dts?
> Or is more work required to get at least "lspci" working?

You will need to adjust the ranges of the PCIe bus, but nothing more is
required to get the endpoint atleast detected. See here:

https://github.com/blocktrron/openwrt/commit/1766b385d6500abdd6a32c33007c47da62e2b757

Maybe we sould add this commented-out to the devicetree? I see no point
in enabling the PCIe bus for a currently non-working device.


>> DECT:  Dialog SC14448
>>currently not supported
> (hm, seems to be a spi? chip)

It seems to be UART and PCM attached. At least the AVM Firmware smashes
the Firmware for the chip over the UART while booting. There is very
little information about the Chip available only. I assume it's AVM
proprietary so i didn't bother with it.

>> WiFi2: IPQ4019 2T2R 2SS b/g/n
>> WiFi5: IPQ4019 2T2R 2SS n/ac
>> LED:- Power/DSL green
>> - WLAN green
>> - FON/DECT green
>> - Connect/WPS green
>> - Info green
>> - Info red
>> BTN:- WLAN
>> - FON
>> - WPS/Connect
>> UART:  115200n8 3.3V (located under the Dialog chip)
>>VCC - RX - TX - GND (Square is VCC)
>>  [...]
>> diff --git a/target/linux/ipq40xx/base-files/etc/board.d/01_leds 
>> b/target/linux/ipq40xx/base-files/etc/board.d/01_leds
>> index 9105bf2452..39383f4fa8 100755
>> --- a/target/linux/ipq40xx/base-files/etc/board.d/01_leds
>> +++ b/target/linux/ipq40xx/base-files/etc/board.d/01_leds
>> @@ -28,6 +28,7 @@ engenius,eap1300)
>>  ucidef_set_led_wlan "wlan5g" "WLAN5G" "${boardname}:yellow:wlan5g" 
>> "phy1tpt"
>>  ucidef_set_led_default "mesh" "MESH" "${boardname}:blue:mesh" "0"
>>  ;;
>> +avm,fritzbox-7530 |\
> With this addtion, you could just move the ucidef_set_led_wlan entry in front
> of engenius,eap1300 device.

I would prefer the above solution to keep it target-consistent.

> Or you could maybe instead place the
> 
> linux,default-trigger = "phy0tpt";
> 
> property into the DTS (fritzbox-7530:green:wlan's node) to do the same job.
>  
>>  glinet,gl-b1300)
>>  ucidef_set_led_wlan "wlan" "WLAN" "${boardname}:green:wlan" "phy0tpt"
>>  ;;
>> diff --git 
>> a/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata 
>> b/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
>> index 69b6c2591c..b4252f0ea6 100644
>> --- 
>> a/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
>> +++ 
>> b/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
>> @@ -126,6 +126,9 @@ case "$FIRMWARE" in
>>  avm,fritzbox-4040)
>>  /usr/bin/fritz_cal_extract -i 1 -s 0x400 -e 0x207 -l 12064 -o 
>> /lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader_config")
>>  ;;
>> +avm,fritzbox-7530)
>> +/usr/bin/fritz_cal_extract -i 1 -s 0x3C000 -e 0x207 -l 16384 -o 
>> /lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader0")
> Oh, I think I remember this from the FB4040 as well. It too had 16384 long
> caldata. But everything after byte 12064 was just more padding. That why
> I cut it down to make sure not to push any garbage into the running firmware,
> because from what I remember, the ath10k will take anything from the pre-cal
> at face-value.

Great info, i'm going to check this!

> 
>> +;;
>>  meraki,mr33)
>>  ath10kcal_ubi_extract "ART" 4096 12064
>>  ath10kcal_is_caldata_valid "202f" || ath10kcal_extract "ART" 
>> 4096 12064
>> @@ -164,6 +167,9 @@ case "$FIRMWARE" in
>>  avm,fritzbox-4040)
>>  /usr/bin/fritz_cal_extract -i 1 -s 0x400 -e 0x208 -l 12064 -o 
>> /lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader_config")
>>  ;;
>> +avm,fritzbox-7530)
>> +/usr/bin/fritz_cal_extract -i 1 -s 0x3C800 -e 0x208 -l 16384 -o 
>> /lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader1")
>> +;;
> Oh, so if the urlader1 has the same values as urlader0, you could check the 
> return
> status of fritz_cal_extract and if it failed, then follow up with a fallback 
> to read
> from the other urlader config area.
> 
> something like:
> 
> /usr/bin/fritz_cal_extract -i 1 -s 0x3C800 -e 0x208 -l 12064 -o 
> /lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader0") || \
> /usr/bin/fritz_cal_extract -i 1 -s 0x3C800 -e 0x208 -l 12064 -o 
> /lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader1")

Yeah, this is possible as the data is stored in both partitions. I
decided to go for urlader1 as the pointers for the mac-address point
into urlader1, even the ones in urlader0 (see the U-Boot 

Re: [OpenWrt-Devel] [PATCH 3/3] ipq40xx: add support for FritzBox 7530

[Daniel Golle]

On Tue, Feb 12, 2019 at 08:55:37PM +0100, David Bauer wrote:> 
> >> DECT:  Dialog SC14448
> >>currently not supported
> > (hm, seems to be a spi? chip)
> 
> It seems to be UART and PCM attached. At least the AVM Firmware smashes
> the Firmware for the chip over the UART while booting. There is very
> little information about the Chip available only. I assume it's AVM
> proprietary so i didn't bother with it.

So OsmocomDECT may work on that chips with relatively small effort
and dumped firmware blob. See also:

http://dect.osmocom.org/

http://lists.osmocom.org/pipermail/linux-dect/2017-March/000249.html

https://openwrt-devel.openwrt.narkive.com/eZMxItdJ/patch-rfc-osmocom-dect-stack-on-openwrt

https://lists.openwrt.org/pipermail/openwrt-devel/2017-February/006399.html


Cheers


Daniel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] apm821xx, ath79, lantiq, ramips: move named gpio exports to generic

[Petr Štetiar]

Mathias Kresin  [2019-02-12 23:19:24]:

> 12/02/2019 20:49, Daniel Golle:
> > The patch was copied to a bunch of platforms and seems to be a quite
> > useful feature for various things. Move it to generic to avoid code
> > duplication.
> 
> Follow up to the discussion in
> https://github.com/openwrt/openwrt/pull/1814#issuecomment-462942022.
> 
> We should rather try to get rid of the patch instead of encourage people of
> using it. Has to be read as soft NAK.
> 
> The patch was a hack for missing kernel functionality and was rejected
> upstream a long time ago. The main use case for the patch is pulling reset
> GPIOs or enable a USB VCC supply. More and more drivers/subsystems are
> getting support to control reset GPIOs or enable the VCC supply on their
> own.
> 
> The upstream answer to gpio-exports are gpio-hogs. It is just that nobody
> migrated the devicetree source files to GPIO hogs so far. Even if gpio-hogs
> are still a workaround for drivers not able pull their reset GPIOs/enable
> VCC supply, it seem to me the cleaner workaround.

I've sent RFC[1] about userspace replacement as well.

1. http://lists.infradead.org/pipermail/openwrt-devel/2019-February/015715.html

-- ynezz

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 3/3] ipq40xx: add support for FritzBox 7530

[David Bauer]

On 12.02.19 22:17, Christian Lamparter wrote:
> On Tuesday, February 12, 2019 8:55:37 PM CET David Bauer wrote:
>> Hi Christian,
>> On 11.02.19 23:15, Christian Lamparter wrote:
>>> Comments inline.
>>>
>>> On Sunday, February 10, 2019 2:34:30 PM CET David Bauer wrote:
 Hardware
 
 CPU:   Qualcomm IPQ4019
 RAM:   256M
 FLASH: 128M NAND
 ETH:   QCA8075
 VDSL:  Intel/Lantiq VRX518 PCIe attached
currently not supported
>>>
>>> Does the pcie device show up during boot when
>>> you add and enable the pcie nodes in the dts?
>>> Or is more work required to get at least "lspci" working?
>>
>> You will need to adjust the ranges of the PCIe bus, but nothing more is
>> required to get the endpoint atleast detected. See here:
>>
>> https://github.com/blocktrron/openwrt/commit/1766b385d6500abdd6a32c33007c47da62e2b757
>>
>> Maybe we sould add this commented-out to the devicetree? I see no point
>> in enabling the PCIe bus for a currently non-working device.
> 
> Man, this "just" (in QCOM time) got patched :-/.
> 
> (This went into 4.20):
> 
> 

I'm aware of this patch but i'm not aure if we might indeed have
problems with other devices and the bigger memory space. But i also have
no other device to test this with, soo.

> 
> From what I can tell, the pcie DSL device just does not
> have enough "real-estate". Do you maybe have some bootlogs
> of your 7530 device around when it's doing the pcie initialization?
> (Having bootlogs of both the vendor and openwrt would be great, especially
> openwrt in both configurations: the current, failing one and the working one).

I can provide you with the snippet of working initialization in OpenWRT
and from the vendor for now. I recall it was complaining about not
enough space in the BAR when not altering the range in the device tree.

AVM:

[0.333513] qcom-pcie 4000.pci: link up
[0.333779] qcom-pcie 4000.pci: PCI host bridge to bus :00
[0.333807] pci_bus :00: root bus resource [bus 00-ff]
[0.333833] pci_bus :00: root bus resource [io  0x-0xf]
(bus address [0x4020-0x402f])
[0.333854] pci_bus :00: root bus resource [mem
0x4800-0x57ff]
[0.333904] pci :00:00.0: [1bef:0030] type 01 class 0x060400
[0.333952] pci :00:00.0: reg 0x10: [mem 0x-0x0fff]
[0.334035] pci :00:00.0: PME# supported from D0 D3hot D3cold
[0.334411] PCI: bus0: Fast back to back transfers disabled
[0.334664] pci :01:00.0: [8086:09a9] type 00 class 0x028000
[0.334823] pci :01:00.0: reg 0x10: [mem 0x-0x007f]
[0.335209] pci :01:00.0: supports D1 D2
[0.335229] pci :01:00.0: PME# supported from D0 D1 D3hot D3cold
[0.335593] PCI: bus1: Fast back to back transfers disabled
[0.335746] pci :00:00.0: BAR 8: assigned [mem 0x4800-0x487f]
[0.335774] pci :00:00.0: BAR 0: assigned [mem 0x4880-0x48800fff]
[0.335805] pci :01:00.0: BAR 0: assigned [mem 0x4800-0x487f]
[0.335840] pci :00:00.0: PCI bridge to [bus 01]
[0.335863] pci :00:00.0:   bridge window [mem 0x4800-0x487f]

OpenWRT working:
[0.339504] qcom-pcie 4000.pci: link up
[0.339656] qcom-pcie 4000.pci: PCI host bridge to bus :00
[0.339677] pci_bus :00: root bus resource [bus 00-ff]
[0.339693] pci_bus :00: root bus resource [io  0x-0xf]
(bus address [0x4020-0x402f])
[0.339706] pci_bus :00: root bus resource [mem
0x4800-0x57ff]
[0.340029] PCI: bus0: Fast back to back transfers disabled
[0.341058] PCI: bus1: Fast back to back transfers disabled
[0.341108] pci :00:00.0: BAR 8: assigned [mem 0x4800-0x487f]
[0.341126] pci :00:00.0: BAR 0: assigned [mem
0x4880-0x48800fff 64bit]
[0.341150] pci :01:00.0: BAR 0: assigned [mem 0x4800-0x487f]
[0.341179] pci :00:00.0: PCI bridge to [bus 01-ff]
[0.341194] pci :00:00.0:   bridge window [mem 0x4800-0x487f]


> Because the fix (bigger area) should definitely be sent upstream.
> 
> As for adding the pcie node: please do. I think it's fine to have
> it, even if the driver for the VDSL chip isn't working. 

Okay, will do so.

If anyone is interested: there are some resources for the modem chip
here, but they originate from a GRX350 UGW, so it's most likely platform
specific:

https://github.com/blocktrron/vrx518-pcie
https://github.com/blocktrron/vrx518-mei
https://github.com/blocktrron/vrx518-dsl-cpe-api

 DECT:  Dialog SC14448
currently not supported
>>> (hm, seems to be a spi? chip)
>>
>> It seems to be UART and PCM attached. At least the AVM Firmware smashes
>> the Firmware for the chip over the UART while booting. There is very
>> little information about the Chip 

Re: [OpenWrt-Devel] [PATCH] apm821xx, ath79, lantiq, ramips: move named gpio exports to generic

[Mathias Kresin]

12/02/2019 20:49, Daniel Golle:

The patch was copied to a bunch of platforms and seems to be a quite
useful feature for various things. Move it to generic to avoid code
duplication.


Follow up to the discussion in 
https://github.com/openwrt/openwrt/pull/1814#issuecomment-462942022.


We should rather try to get rid of the patch instead of encourage people 
of using it. Has to be read as soft NAK.


The patch was a hack for missing kernel functionality and was rejected 
upstream a long time ago. The main use case for the patch is pulling 
reset GPIOs or enable a USB VCC supply. More and more drivers/subsystems 
are getting support to control reset GPIOs or enable the VCC supply on 
their own.


The upstream answer to gpio-exports are gpio-hogs. It is just that 
nobody migrated the devicetree source files to GPIO hogs so far. Even if 
gpio-hogs are still a workaround for drivers not able pull their reset 
GPIOs/enable VCC supply, it seem to me the cleaner workaround.


Mathias

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Cleanup in 4.19 generic kernel config?

[Rosen Penev]

On Sat, Feb 9, 2019 at 12:16 AM Daniel Engberg
 wrote:
>
> Hi,
>
> After my attempt getting Linux 4.19 working for the Octeon target
> I started to look at the generic configuration for 4.19 and it
> seems that there are quite a bit of target specific options listed
> and potentially generating larger kernels than necessary.
> Given that some options are incorrect for certain targets I assume
> that they get overridden and/or ignored. Unless I misunderstand
> how the Linux kernel configuration works =y is equivalent to always
> compiled into kernel?
>
> I'm taking about this file by the way:
> https://github.com/openwrt/openwrt/blob/master/target/linux/generic/config-4.19
>
> Should be set by target? Shouldn't coexist with CONFIG_64BIT as
> far as I can tell.
> CONFIG_32BIT=y
>
> ARM specific, should be set by target?
> CONFIG_ARM_CPU_TOPOLOGY=y
> CONFIG_ARM_DMA_MEM_BUFFERABLE=y
> CONFIG_ARM_GIC_MAX_NR=1
>
> Target specific, no need to have it enabled by default and/or
> possibly at all?
> CONFIG_ATA_BMDMA=y
> CONFIG_ATA_SFF=y
>
> Seems to be defined by default?
> CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
> https://github.com/torvalds/linux/blob/master/drivers/block/Kconfig#L217
>
> Should be set by target?
> CONFIG_BOOKE_WDT_DEFAULT_TIMEOUT=3
>
> Debug option - Adds unnecessary overhead?
> CONFIG_BRANCH_PROFILE_NONE=y
> https://cateee.net/lkddb/web-lkddb/BRANCH_PROFILE_NONE.html
>
> Should be set by target (ARM)?
> CONFIG_CACHE_L2X0_PMU=y
>
> Should be set by target, why is it enabled in 2019?
> CONFIG_CARDBUS=y
>
> Should be set by target (seems x86/64x specific)?
> CONFIG_DOUBLEFAULT=y
>
> Gets defined automatically based on target/platform?
> CONFIG_HZ=100
> CONFIG_HZ_100=y
>
> Already default?
> CONFIG_IIO_CONSUMERS_PER_TRIGGER=2
> https://cateee.net/lkddb/web-lkddb/IIO_CONSUMERS_PER_TRIGGER.html
>
> Why?
> CONFIG_ISDN=y
> CONFIG_JOLIET=y
>
> Should be set by target (ARM)?
> CONFIG_KERNEL_MODE_NEON=y
>
> Set Page_Size by target?
> CONFIG_PAGE_SIZE_4KB=y
> CONFIG_PPC_4K_PAGES=y
>
> Already default?
> CONFIG_PWRSEQ_EMMC=y
> https://cateee.net/lkddb/web-lkddb/PWRSEQ_EMMC.html
>
> Default 21 isn't enough?
> CONFIG_RCU_CPU_STALL_TIMEOUT=60
>
> Needed for?
> CONFIG_RXKAD=y
>
> Obsolete?
> CONFIG_SLABINFO=y
>
> Shouldn't be default and/or platform specific?
> CONFIG_SND_X86=y
>
> Needed for?
> CONFIG_USB_ARMLINUX=y
> CONFIG_USB_BELKIN=y
>
> Platform specific?
> CONFIG_USB_OHCI_LITTLE_ENDIAN=y
>
> Platform specific?
> CONFIG_X86_SYSFB=y
>
> Best regads,
> Daniel
I've been running this with ramips for a few days. No issues to report.
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] kernel: Remove CONFIG_UDF_NLS for kernel 4.19

[Rosen Penev]

kernel 4.18 removed the symbol and made NLS implicit.

Signed-off-by: Rosen Penev 
---
 target/linux/generic/config-4.19 | 1 -
 1 file changed, 1 deletion(-)

diff --git a/target/linux/generic/config-4.19 b/target/linux/generic/config-4.19
index 65d908ffe7..5e9a6cf624 100644
--- a/target/linux/generic/config-4.19
+++ b/target/linux/generic/config-4.19
@@ -5300,7 +5300,6 @@ CONFIG_UBIFS_FS_FORMAT4=y
 # CONFIG_UCB1400_CORE is not set
 # CONFIG_UCSI is not set
 # CONFIG_UDF_FS is not set
-CONFIG_UDF_NLS=y
 CONFIG_UEVENT_HELPER=y
 CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
 # CONFIG_UFS_FS is not set
-- 
2.17.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 3/3] ipq40xx: add support for FritzBox 7530

[Christian Lamparter]

On Tuesday, February 12, 2019 8:55:37 PM CET David Bauer wrote:
> Hi Christian,
> On 11.02.19 23:15, Christian Lamparter wrote:
> > Comments inline.
> > 
> > On Sunday, February 10, 2019 2:34:30 PM CET David Bauer wrote:
> >> Hardware
> >> 
> >> CPU:   Qualcomm IPQ4019
> >> RAM:   256M
> >> FLASH: 128M NAND
> >> ETH:   QCA8075
> >> VDSL:  Intel/Lantiq VRX518 PCIe attached
> >>currently not supported
> > 
> > Does the pcie device show up during boot when
> > you add and enable the pcie nodes in the dts?
> > Or is more work required to get at least "lspci" working?
> 
> You will need to adjust the ranges of the PCIe bus, but nothing more is
> required to get the endpoint atleast detected. See here:
> 
> https://github.com/blocktrron/openwrt/commit/1766b385d6500abdd6a32c33007c47da62e2b757
> 
> Maybe we sould add this commented-out to the devicetree? I see no point
> in enabling the PCIe bus for a currently non-working device.

Man, this "just" (in QCOM time) got patched :-/.

(This went into 4.20):



>From what I can tell, the pcie DSL device just does not
have enough "real-estate". Do you maybe have some bootlogs
of your 7530 device around when it's doing the pcie initialization?
(Having bootlogs of both the vendor and openwrt would be great, especially
openwrt in both configurations: the current, failing one and the working one).

Because the fix (bigger area) should definitely be sent upstream.

As for adding the pcie node: please do. I think it's fine to have
it, even if the driver for the VDSL chip isn't working. 

> >> DECT:  Dialog SC14448
> >>currently not supported
> > (hm, seems to be a spi? chip)
> 
> It seems to be UART and PCM attached. At least the AVM Firmware smashes
> the Firmware for the chip over the UART while booting. There is very
> little information about the Chip available only. I assume it's AVM
> proprietary so i didn't bother with it.
Oh ok. "Good to know". I guess this would then also require I2S support...
which is non-existent at the moment.

> >> WiFi2: IPQ4019 2T2R 2SS b/g/n
> >> WiFi5: IPQ4019 2T2R 2SS n/ac
> >> LED:- Power/DSL green
> >> - WLAN green
> >> - FON/DECT green
> >> - Connect/WPS green
> >> - Info green
> >> - Info red
> >> BTN:- WLAN
> >> - FON
> >> - WPS/Connect
> >> UART:  115200n8 3.3V (located under the Dialog chip)
> >>VCC - RX - TX - GND (Square is VCC)
> >>  [...]
> >> diff --git a/target/linux/ipq40xx/base-files/etc/board.d/01_leds 
> >> b/target/linux/ipq40xx/base-files/etc/board.d/01_leds
> >> index 9105bf2452..39383f4fa8 100755
> >> --- a/target/linux/ipq40xx/base-files/etc/board.d/01_leds
> >> +++ b/target/linux/ipq40xx/base-files/etc/board.d/01_leds
> >> @@ -28,6 +28,7 @@ engenius,eap1300)
> >>ucidef_set_led_wlan "wlan5g" "WLAN5G" "${boardname}:yellow:wlan5g" 
> >> "phy1tpt"
> >>ucidef_set_led_default "mesh" "MESH" "${boardname}:blue:mesh" "0"
> >>;;
> >> +avm,fritzbox-7530 |\
> > With this addtion, you could just move the ucidef_set_led_wlan entry in 
> > front
> > of engenius,eap1300 device.
> 
> I would prefer the above solution to keep it target-consistent.
K. Keep it as is then (just move it)
 
> >> diff --git 
> >> a/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
> >>  
> >> b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
> >> new file mode 100644
> >> index 00..ea2d70a8bd
> >> --- /dev/null
> >> +++ 
> >> b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
> >> @@ -0,0 +1,281 @@
> >> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> >> +
> >> +#include "qcom-ipq4019.dtsi"
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +/ {

I just remembered that the rng-node was missing in the soc-subnode.
Robert Marko discovered this while porting the 4.19. We didn't add
it for the 4.14 because the qcom rng driver only registers with a
crypto_rng device. While this is still useful (stdrng), it is not
a true random number generator. 

But nevertheless: can you please add:

rng@22000 {
status = "okay";
};

to 4.19's dts?

> >> diff --git a/target/linux/ipq40xx/image/Makefile 
> >> b/target/linux/ipq40xx/image/Makefile
> >> index a670380ab3..ca5a453b47 100644
> >> --- a/target/linux/ipq40xx/image/Makefile
> >> +++ b/target/linux/ipq40xx/image/Makefile
> >> @@ -97,6 +97,15 @@ define Device/avm_fritzbox-4040
> >>  endef
> >>  TARGET_DEVICES += avm_fritzbox-4040
> >>  
> >> +define Device/avm_fritzbox-7530
> >> +  $(call Device/FitImageLzma)
> >> +  DEVICE_DTS := qcom-ipq4019-fritzbox-7530
> >> +  DEVICE_TITLE := AVM Fritz!Box 7530
> >> +  DEVICE_PACKAGES := fritz-caldata ipq-wifi-fritz7530
> > I remember seeing a 

Re: [OpenWrt-Devel] [PATCH 3/3] ipq40xx: add support for FritzBox 7530

[Christian Lamparter]

Comments inline.

On Sunday, February 10, 2019 2:34:30 PM CET David Bauer wrote:
> Hardware
> 
> CPU:   Qualcomm IPQ4019
> RAM:   256M
> FLASH: 128M NAND
> ETH:   QCA8075
> VDSL:  Intel/Lantiq VRX518 PCIe attached
>currently not supported

Does the pcie device show up during boot when
you add and enable the pcie nodes in the dts?
Or is more work required to get at least "lspci" working?

> DECT:  Dialog SC14448
>currently not supported
(hm, seems to be a spi? chip)

> WiFi2: IPQ4019 2T2R 2SS b/g/n
> WiFi5: IPQ4019 2T2R 2SS n/ac
> LED:- Power/DSL green
> - WLAN green
> - FON/DECT green
> - Connect/WPS green
> - Info green
> - Info red
> BTN:- WLAN
> - FON
> - WPS/Connect
> UART:  115200n8 3.3V (located under the Dialog chip)
>VCC - RX - TX - GND (Square is VCC)
>  [...]
> diff --git a/target/linux/ipq40xx/base-files/etc/board.d/01_leds 
> b/target/linux/ipq40xx/base-files/etc/board.d/01_leds
> index 9105bf2452..39383f4fa8 100755
> --- a/target/linux/ipq40xx/base-files/etc/board.d/01_leds
> +++ b/target/linux/ipq40xx/base-files/etc/board.d/01_leds
> @@ -28,6 +28,7 @@ engenius,eap1300)
>   ucidef_set_led_wlan "wlan5g" "WLAN5G" "${boardname}:yellow:wlan5g" 
> "phy1tpt"
>   ucidef_set_led_default "mesh" "MESH" "${boardname}:blue:mesh" "0"
>   ;;
> +avm,fritzbox-7530 |\
With this addtion, you could just move the ucidef_set_led_wlan entry in front
of engenius,eap1300 device.

Or you could maybe instead place the

linux,default-trigger = "phy0tpt";

property into the DTS (fritzbox-7530:green:wlan's node) to do the same job.
 
>  glinet,gl-b1300)
>   ucidef_set_led_wlan "wlan" "WLAN" "${boardname}:green:wlan" "phy0tpt"
>   ;;
> diff --git 
> a/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata 
> b/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> index 69b6c2591c..b4252f0ea6 100644
> --- a/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> +++ b/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> @@ -126,6 +126,9 @@ case "$FIRMWARE" in
>   avm,fritzbox-4040)
>   /usr/bin/fritz_cal_extract -i 1 -s 0x400 -e 0x207 -l 12064 -o 
> /lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader_config")
>   ;;
> + avm,fritzbox-7530)
> + /usr/bin/fritz_cal_extract -i 1 -s 0x3C000 -e 0x207 -l 16384 -o 
> /lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader0")
Oh, I think I remember this from the FB4040 as well. It too had 16384 long
caldata. But everything after byte 12064 was just more padding. That why
I cut it down to make sure not to push any garbage into the running firmware,
because from what I remember, the ath10k will take anything from the pre-cal
at face-value.

> + ;;
>   meraki,mr33)
>   ath10kcal_ubi_extract "ART" 4096 12064
>   ath10kcal_is_caldata_valid "202f" || ath10kcal_extract "ART" 
> 4096 12064
> @@ -164,6 +167,9 @@ case "$FIRMWARE" in
>   avm,fritzbox-4040)
>   /usr/bin/fritz_cal_extract -i 1 -s 0x400 -e 0x208 -l 12064 -o 
> /lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader_config")
>   ;;
> + avm,fritzbox-7530)
> + /usr/bin/fritz_cal_extract -i 1 -s 0x3C800 -e 0x208 -l 16384 -o 
> /lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader1")
> + ;;
Oh, so if the urlader1 has the same values as urlader0, you could check the 
return
status of fritz_cal_extract and if it failed, then follow up with a fallback to 
read
from the other urlader config area.

something like:

/usr/bin/fritz_cal_extract -i 1 -s 0x3C800 -e 0x208 -l 12064 -o 
/lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader0") || \
/usr/bin/fritz_cal_extract -i 1 -s 0x3C800 -e 0x208 -l 12064 -o 
/lib/firmware/$FIRMWARE $(find_mtd_chardev "urlader1")

> diff --git 
> a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
>  
> b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
> new file mode 100644
> index 00..ea2d70a8bd
> --- /dev/null
> +++ 
> b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-fritzbox-7530.dts
> + leds {
> + compatible = "gpio-leds";
> +
> + info_red: info_red {
> + label = "fritzbox-7530:red:info";
> + gpios = < 32 GPIO_ACTIVE_LOW>;
> + };
> +
> + info_green: info {
> + label = "fritzbox-7530:green:info";
> + gpios = < 33 GPIO_ACTIVE_LOW>;
> + };
> +
> + wlan {
> + label = "fritzbox-7530:green:wlan";
> + gpios = < 34 GPIO_ACTIVE_LOW>;
   (and the same place in 4.19's dts)
> + };
> +
> + fon {
> + label = "fritzbox-7530:green:fon";
> + gpios = < 35 

Re: [OpenWrt-Devel] [PATCH v2] ramips: various Netgear R6120 fixes

[Ilya K]

Can confirm this patch is working extremely well on my R6120. Any way I can 
help in getting this upstreamed?

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel