Re: [OpenWrt-Devel] [PATCH v2 0/7] MIPS: lantiq: irq: Various fixes, add SMP support

[Paul Burton]

Hello,

petrcve...@gmail.com wrote:
> From: Petr Cvek 
> 
> Hi,
> 
> While hacking with my modem in openwrt I've found in the lantiq vrx268 SoC
> there is only a support for the processes SMP and not for interrupt
> routing. After some looking into vendors released source codes (probably
> intel UGW) and by observing SoC's memory map I've found out there is
> a second interrupt controller (ICU) for the second VPE. The last patch of
> this series adds a support for it. The code is different from intel UGW's
> set affinity function, where the interrupt line gets enabled (switched)
> to the second ICU. Instead only the cpumask gets changed in my set affinity.
> The change will be written into the hardware after the next irq enable call.
> This was changed because of stability reasons in the high irq load of
> the SoC.
> 
> The first part of the series are more or less cosmetic changes of long
> names, different types and few fixed warnings from checkpatch. There is
> a fix in part 5, where I've found the missing bitfield clear before ORing
> with a new value.
> 
> The SMP in part 7 changes devicetree definition for a register regions
> of the ICU. Previously, there was a region for a single IM (a mask/unmask/
> enable/... set for 32 interrupts). Now it is the whole ICU. It match more
> the hardware layout. There is no compatibility issue in vanilla, only
> openwrt was affected by these devicetrees.
> 
> Also in the UGW's ltq_enable_irq(), there was a status bit reset before
> the actual IRQ line enable. It was marked as "Bug fix for fake interrupt".
> The code seems to work without it (vanilla and new SMP), but I've made
> an assert if this bit is set before the actual enable. The assert reported
> these IRQ sources:
> 
> 22:4000 spi_rx  (only when SPI is accessed)
> 63:0080 mei_cpe (permanent 1s)
> 112:0100asc_tx
> 
> But the code seems to run anyway I didn't include the status bit reset part.
> 
> The SMP affinity update is done every IRQ enable, where it extract the first
> valid VPE from affinity cpumask. This is standard in the kernel.
> 
> The code was tested in nosmp configuration on TPLink W9980B in openwrt tree
> (patched kernel v4.14). The lantiq devices other than vrx268 were not
> tested.
> 
> Discussion on openwrt related parts for lantiq ICU SMP is here (devicetrees,
> things not in the vanilla kernel, RFC versions of the patch):
> https://patchwork.ozlabs.org/patch/1100832/
> 
> Changes since v1:
> * Added a define for IM size
> * Changed ltq_icu_membase array size to NR_CPUS so for_each_possible_cpu()
> will not overflow
> * Removed affinity auto rotation (can be add later from v1 if required)
> * Commit messages wordings
> 
> Petr Cvek (7):
> MIPS: lantiq: Move macro directly to iomem function
> MIPS: lantiq: Change variables to the same type as the source
> MIPS: lantiq: Fix attributes of of_device_id structure
> MIPS: lantiq: Remove unused macros
> MIPS: lantiq: Fix bitfield masking
> MIPS: lantiq: Shorten register names, remove unused macros
> MIPS: lantiq: Add SMP support for lantiq interrupt controller
> 
> arch/mips/lantiq/irq.c | 177 +
> 1 file changed, 126 insertions(+), 51 deletions(-)

Series applied to mips-next.

Thanks,
Paul

[ This message was auto-generated; if you believe anything is incorrect
  then please email paul.bur...@mips.com to report it. ]
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] toolchain: Don't force GCC8 on ARC

[Christian Lamparter]

On Monday, June 24, 2019 10:01:51 PM CEST Rosen Penev wrote:
> On Mon, Jun 24, 2019 at 1:00 PM Christian Lamparter  
> wrote:
> >
> > On Saturday, June 22, 2019 8:57:32 PM CEST Rosen Penev wrote:
> > > On Sat, Jun 22, 2019 at 7:37 AM Christian Lamparter  
> > > wrote:
> > > >
> > > > On Thursday, June 20, 2019 9:33:04 PM CEST Rosen Penev wrote:
> > > > > This prevents overriding it to use GCC9.
> > > > >
> > > > > Signed-off-by: Rosen Penev 
> > > > > ---
> > > > >  toolchain/gcc/Config.version | 1 -
> > > > >  1 file changed, 1 deletion(-)
> > > > >
> > > > > diff --git a/toolchain/gcc/Config.version 
> > > > > b/toolchain/gcc/Config.version
> > > > > index ef9bbb82e2..e635244827 100644
> > > > > --- a/toolchain/gcc/Config.version
> > > > > +++ b/toolchain/gcc/Config.version
> > > > > @@ -4,7 +4,6 @@ config GCC_VERSION_5
> > > > >
> > > > >  config GCC_VERSION_8
> > > > >   default y if GCC_USE_VERSION_8
> > > > > - default y if arc
> > > > >   bool
> > > > >
> > > > >  config GCC_VERSION_9
> > > > >
> > > > From what I know this would select the default GCC 7.4.
> > > It does. On the other hand, if you select Advanced options and select
> > > to build GCC9, it still builds GCC8.
> >
> > Yes, problem here are the buildbots. They always go with the default
> > so they would upload images compiled with a broken compiler.
> >
> > There seems to be also a interaction with toolchain/gcc/Config.in
> >
> > |choice
> > |prompt "GCC compiler Version" if TOOLCHAINOPTS
> > |default GCC_USE_VERSION_8 if arc
> > |default GCC_USE_VERSION_7
> > |help
> > |  Select the version of gcc you wish to use.
> > |
> > |config GCC_USE_VERSION_5
> > |bool "gcc 5.x"
> > |depends on !arc
> > |
> > |config GCC_USE_VERSION_7
> > |bool "gcc 7.x"
> > |depends on !arc
> > |
> > |config GCC_USE_VERSION_8
> > |bool "gcc 8.x"
> > |
> > |config GCC_USE_VERSION_9
> > |bool "gcc 9.x"
> > |endchoice
> >
> > I guess this means that one needs to be creative and pile on the
> > other workaround and "fixes". I.e.: something like
> >
> > ---
> > diff --git a/toolchain/gcc/Config.version b/toolchain/gcc/Config.version
> > index ef9bbb82e2..2a9dc289db 100644
> > --- a/toolchain/gcc/Config.version
> > +++ b/toolchain/gcc/Config.version
> > @@ -4,7 +4,7 @@ config GCC_VERSION_5
> >
> >  config GCC_VERSION_8
> > default y if GCC_USE_VERSION_8
> > -   default y if arc
> > +   default y if arc && !GCC_USE_VERSION_9
> > bool
> >
> >  config GCC_VERSION_9
> > ---
> >
> > Question is, do we really want to go down that route? Or is there
> > a better solution? Because this is ugly.
> I see no problem as the solution will be short lived (until GCC7 goes away).

The emphasis was really on "something like". I didn't really test this
properly, so I don't know if it works or has other implications.

Cheers,
Christian



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

Re: [OpenWrt-Devel] [PATCH] ath79: add support for gl-ar750

[Christian Lamparter]

On Monday, June 24, 2019 10:41:37 AM CEST Luochongjun wrote:
> This patch support gl-ar750 on ath79.

I'm looking at this previous patch for the GL-X750.


And I think you can do better than this gl-ar750 post.

Can you please take the time and amend your patch with the
specification and a short description on how the flash the
initial image. Thanks.

More comments down below.

> 
> Signed-off-by: Luo chongjun 
Please make sure your Name matches exactly (as in bit-for-bit) that of
your E-Mail Client address. Otherwise this needs to be fixed by the
commiter since the openwrt infrastructure does a checks that.

> ---
>  .../etc/hotplug.d/firmware/11-ath10k-caldata   |   1 +
>  target/linux/ath79/dts/qca9531_glinet_gl-ar750.dts | 149 
> +
>  target/linux/ath79/image/generic.mk|   8 ++
>  3 files changed, 158 insertions(+)
>  create mode 100644 target/linux/ath79/dts/qca9531_glinet_gl-ar750.dts
> 
> diff --git 
> a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata 
> b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> index 8f0ea1d..6a9cb1c 100644
> --- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> +++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> @@ -116,6 +116,7 @@ case "$FIRMWARE" in
>   ath10kcal_extract "art" 20480 2116
>   ath10kcal_patch_mac $(macaddr_add $(cat 
> /sys/class/net/eth0/address) +1)
>   ;;
> + glinet,gl-ar750|\
>   glinet,gl-ar750s)
>   ath10kcal_extract "art" 20480 2116
>   ath10kcal_patch_mac $(macaddr_add $(mtd_get_mac_binary art 0) 
> +1)
> diff --git a/target/linux/ath79/dts/qca9531_glinet_gl-ar750.dts 
> b/target/linux/ath79/dts/qca9531_glinet_gl-ar750.dts
> new file mode 100644
> index 000..c173f0d
> --- /dev/null
> +++ b/target/linux/ath79/dts/qca9531_glinet_gl-ar750.dts
> @@ -0,0 +1,149 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +/dts-v1/;
> +
> +#include 
> +#include 
> +
> +#include "qca953x.dtsi"
> +
> +/ {
> + compatible = "glinet,gl-ar750", "qca,qca9531";
> + model = "GL.iNet GL-AR750";
> +
> + keys {
> + compatible = "gpio-keys-polled";
ath79 should support "gpio-keys".

> +
> + poll-interval = <20>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_disable_pins>;
> +
> + reset {
> + label = "reset";
> + linux,code = ;
> + gpios = < 3 GPIO_ACTIVE_LOW>;
> + };
> +
> + mode {
> +label = "mode";
> +linux,code = ;
> +gpios = < 0 GPIO_ACTIVE_LOW>;
> +};
Please use tabs instead of space for indent.
(scripts/checkpatch.pl can help you find these cases).
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + power {
> + label = "gl-ar750:green:power";
> + gpios = < 12 GPIO_ACTIVE_LOW>;
> + default-state = "on";
> + };
> +
> + wlan2g {
> + label = "gl-ar750:green:wlan2g";
> + gpios = < 14 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "phy1tpt";
> + };
> +
> + wlan5g {
> + label = "gl-ar750:green:wlan5g";
> + gpios = < 13 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "phy0tpt";
> + };
> +
> + };
> +
> +   i2c {
> +compatible = "i2c-gpio";
> +
> +sda-gpios = < 17 GPIO_ACTIVE_LOW>;
> +scl-gpios = < 16 GPIO_ACTIVE_LOW>;
> +
> +/* can be removed on 4.19 */
> +gpios = < 17 GPIO_ACTIVE_LOW>,
> +< 16 GPIO_ACTIVE_LOW>;
Hm, ath79 switched to 4.19. So they can be removed right now ;)
> +
> +};
> +
> +
> +};
> +
> + {
> + status = "okay";
Please add a proper sub node with the right ath10k compatible
(see qcom,ath10k.txt) for the attached pcie chip here.

> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "okay";
> +
> + hub_port: port@1 {
> + reg = <1>;
> + #trigger-source-cells = <0>;
> + };
> +};
> +
> +_phy {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> + num-cs = <0>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <2500>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + 

Re: [OpenWrt-Devel] [PATCH] ramips: mt7621: Add new device AsiaRF AP7621-001

[Christian Lamparter]

On Monday, June 24, 2019 6:13:20 PM CEST Daniel Danzberger wrote:
> SoC:Mediatek MT7621A
> CPU:4x 880Mhz
> Cache:  32 KB I-Cache and 32 KB D-Cach
> 256 KB L2 Cache (shared by Dual-Core)
> RAM:DDR3 512MB 16bits BUS
> FLASH:  16MB
> Switch: Mediatek Gigabit Switch (1 x LAN, 1 x WAN)
> USB:1x 3.0
> PCI:3x Mini PCIe
> GPS:Quectel L70B
> BTN:Reset
> LED:- Power
> - Ethernet
> - Wifi
> - USB
> UART:  UART is present as Pads with throughholes on the PCB.
>  They are located on left side.
>3.3V - RX - GND - TX / 57600-8N1
>3.3V is the square pad
> 
> Installation
> 
> The stock image is a modified openwrt and can be overflashed via 
> sysupgrade -F
> 
> Signed-off-by: Daniel Danzberger 
> ---
>  .../ramips/base-files/etc/board.d/02_network  |   3 +
>  target/linux/ramips/dts/AP7621-001.dts| 127 ++
>  target/linux/ramips/image/mt7621.mk   |  10 ++
>  3 files changed, 140 insertions(+)
>  create mode 100644 target/linux/ramips/dts/AP7621-001.dts
> 
> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
> b/target/linux/ramips/base-files/etc/board.d/02_network
> index 52204eacbf..ffd1689263 100755
> --- a/target/linux/ramips/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> @@ -39,6 +39,9 @@ ramips_setup_interfaces()
>   ucidef_add_switch "switch0" \
>   "0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "4:wan:5" 
> "6@eth0"
>   ;;
> + asiarf,ap7621-001)
> + ucidef_add_switch "switch0" "0:lan" "4:wan" "6@eth0"
> + ;;
>   3g150b|\
>   3g300m|\
>   a5-v11|\
> diff --git a/target/linux/ramips/dts/AP7621-001.dts 
> b/target/linux/ramips/dts/AP7621-001.dts
> new file mode 100644
> index 00..daab06ec90
> --- /dev/null
> +++ b/target/linux/ramips/dts/AP7621-001.dts
> @@ -0,0 +1,127 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +
> +/dts-v1/;
> +#include "mt7621.dtsi"
> +
> +#include 
> +#include 
> +
> +/ {
> + compatible = "asiarf,ap7621-001", "mediatek,mt7621-soc";
> + model = "AP7621-001";

Oh boy, this is tricky.


'The recommended format ' (for the root node!) ' is 
"manufacturer,model-number".'

BUT. Thing is, this string here gets printed on the LuCI system
page and from past experience "Manugacturer Model" works best.

> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x1c00>, <0x2000 0x400>;
> + };
> +
> + chosen {
> + bootargs = "console=ttyS0,57600";
> + };
> +
> + keys {
> + compatible = "gpio-keys";
> +
> + reset {
> + label = "reset";
> + gpios = < 18 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + wlan1 {
> + label = "ap7621-001:orange:wlan1";
> + gpios = < 11 GPIO_ACTIVE_LOW>;
> + };
> +
> + wlan0 {
> + label = "ap7621-001:orange:wlan0";
> + gpios = < 12 GPIO_ACTIVE_LOW>;
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> +status = "okay";
please use tabs here.

> +
> +flash@0 {
> +compatible = "jedec,spi-nor";
> +reg = <0>;
> +spi-max-frequency = <4000>;
> +
> + partitions {
this needs one more tab.
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
please use tabs to ident most of the properies 
for the rest of the node. (scripts/checkpatch.pl will
catch those lines)

> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "u-boot";
> + reg = <0x0 0x3>;
> + read-only;
> + };
> +
> + partition@3 {
> + label = "u-boot-env";
> + reg = <0x3 0x2000>;
needs read-only;
> + };
> +
> + partition@32000 {
> + label = "2860";
> + reg = <0x32000 0x4000>;
needs read-only;

> + };
> +
> + partition@36000 {
> + label = "rtdev";
> + reg = <0x36000 0x2000>;
needs read-only;

> + };
> +
> + 

Re: [OpenWrt-Devel] ath10k-ct crash Archer C7 v2 - OpenWrt r10307-629e6538a1 - k4.19

[Ben Greear]

On 6/24/19 12:34 PM, Kevin 'ldir' Darbyshire-Bryant wrote:




On 24 Jun 2019, at 19:51, Ben Greear  wrote:

On 6/23/19 3:33 AM, Kevin 'ldir' Darbyshire-Bryant wrote:

Unfortunately flyspray won’t let me create a task, so filing this here so it 
doesn’t get lost.
Archer C7 v2 - OpenWrt r10307-629e6538a1 - k4.19
Recently seen the following firmware crashes on the device.  Seems to be 
related to my macbook coming out of power save mode.
There's been a recent ath10k-ct firmware bump so unclear if this is a wireless 
firmware bug or a kernel driver bug, or both.  Maybe the crashlog holds a clue.


Hello,

Does this seem to be a regression, or it never worked well, or you just started 
testing
this type of scenario?

Thanks,
Ben


It’s a regression for me at least.  Not seen it before.


Does it seem to happen often enough to be something you could bisect?

Also, please try the firmware I attached to the previous email to Koen.  It has 
debugging
for the crash you saw.  I have comments in the nearby code from old strange 
issues seen there,
so not sure it is something new or just maybe triggering some old bug.

Thanks,
Ben



Cheers,

Kevin




--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com


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

Re: [OpenWrt-Devel] [PATCH] toolchain: Don't force GCC8 on ARC

[Rosen Penev]

On Mon, Jun 24, 2019 at 1:00 PM Christian Lamparter  wrote:
>
> On Saturday, June 22, 2019 8:57:32 PM CEST Rosen Penev wrote:
> > On Sat, Jun 22, 2019 at 7:37 AM Christian Lamparter  
> > wrote:
> > >
> > > On Thursday, June 20, 2019 9:33:04 PM CEST Rosen Penev wrote:
> > > > This prevents overriding it to use GCC9.
> > > >
> > > > Signed-off-by: Rosen Penev 
> > > > ---
> > > >  toolchain/gcc/Config.version | 1 -
> > > >  1 file changed, 1 deletion(-)
> > > >
> > > > diff --git a/toolchain/gcc/Config.version b/toolchain/gcc/Config.version
> > > > index ef9bbb82e2..e635244827 100644
> > > > --- a/toolchain/gcc/Config.version
> > > > +++ b/toolchain/gcc/Config.version
> > > > @@ -4,7 +4,6 @@ config GCC_VERSION_5
> > > >
> > > >  config GCC_VERSION_8
> > > >   default y if GCC_USE_VERSION_8
> > > > - default y if arc
> > > >   bool
> > > >
> > > >  config GCC_VERSION_9
> > > >
> > > From what I know this would select the default GCC 7.4.
> > It does. On the other hand, if you select Advanced options and select
> > to build GCC9, it still builds GCC8.
>
> Yes, problem here are the buildbots. They always go with the default
> so they would upload images compiled with a broken compiler.
>
> There seems to be also a interaction with toolchain/gcc/Config.in
>
> |choice
> |prompt "GCC compiler Version" if TOOLCHAINOPTS
> |default GCC_USE_VERSION_8 if arc
> |default GCC_USE_VERSION_7
> |help
> |  Select the version of gcc you wish to use.
> |
> |config GCC_USE_VERSION_5
> |bool "gcc 5.x"
> |depends on !arc
> |
> |config GCC_USE_VERSION_7
> |bool "gcc 7.x"
> |depends on !arc
> |
> |config GCC_USE_VERSION_8
> |bool "gcc 8.x"
> |
> |config GCC_USE_VERSION_9
> |bool "gcc 9.x"
> |endchoice
>
> I guess this means that one needs to be creative and pile on the
> other workaround and "fixes". I.e.: something like
>
> ---
> diff --git a/toolchain/gcc/Config.version b/toolchain/gcc/Config.version
> index ef9bbb82e2..2a9dc289db 100644
> --- a/toolchain/gcc/Config.version
> +++ b/toolchain/gcc/Config.version
> @@ -4,7 +4,7 @@ config GCC_VERSION_5
>
>  config GCC_VERSION_8
> default y if GCC_USE_VERSION_8
> -   default y if arc
> +   default y if arc && !GCC_USE_VERSION_9
> bool
>
>  config GCC_VERSION_9
> ---
>
> Question is, do we really want to go down that route? Or is there
> a better solution? Because this is ugly.
I see no problem as the solution will be short lived (until GCC7 goes away).
>
> Regards,
> Christian
>
>

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

Re: [OpenWrt-Devel] [PATCH] toolchain: Don't force GCC8 on ARC

[Christian Lamparter]

On Saturday, June 22, 2019 8:57:32 PM CEST Rosen Penev wrote:
> On Sat, Jun 22, 2019 at 7:37 AM Christian Lamparter  
> wrote:
> >
> > On Thursday, June 20, 2019 9:33:04 PM CEST Rosen Penev wrote:
> > > This prevents overriding it to use GCC9.
> > >
> > > Signed-off-by: Rosen Penev 
> > > ---
> > >  toolchain/gcc/Config.version | 1 -
> > >  1 file changed, 1 deletion(-)
> > >
> > > diff --git a/toolchain/gcc/Config.version b/toolchain/gcc/Config.version
> > > index ef9bbb82e2..e635244827 100644
> > > --- a/toolchain/gcc/Config.version
> > > +++ b/toolchain/gcc/Config.version
> > > @@ -4,7 +4,6 @@ config GCC_VERSION_5
> > >
> > >  config GCC_VERSION_8
> > >   default y if GCC_USE_VERSION_8
> > > - default y if arc
> > >   bool
> > >
> > >  config GCC_VERSION_9
> > >
> > From what I know this would select the default GCC 7.4.
> It does. On the other hand, if you select Advanced options and select
> to build GCC9, it still builds GCC8.

Yes, problem here are the buildbots. They always go with the default
so they would upload images compiled with a broken compiler.

There seems to be also a interaction with toolchain/gcc/Config.in

|choice
|prompt "GCC compiler Version" if TOOLCHAINOPTS
|default GCC_USE_VERSION_8 if arc
|default GCC_USE_VERSION_7
|help
|  Select the version of gcc you wish to use.
|
|config GCC_USE_VERSION_5
|bool "gcc 5.x"
|depends on !arc
|
|config GCC_USE_VERSION_7
|bool "gcc 7.x"
|depends on !arc
|
|config GCC_USE_VERSION_8
|bool "gcc 8.x"
|
|config GCC_USE_VERSION_9
|bool "gcc 9.x"
|endchoice

I guess this means that one needs to be creative and pile on the
other workaround and "fixes". I.e.: something like

---
diff --git a/toolchain/gcc/Config.version b/toolchain/gcc/Config.version
index ef9bbb82e2..2a9dc289db 100644
--- a/toolchain/gcc/Config.version
+++ b/toolchain/gcc/Config.version
@@ -4,7 +4,7 @@ config GCC_VERSION_5
 
 config GCC_VERSION_8
default y if GCC_USE_VERSION_8
-   default y if arc
+   default y if arc && !GCC_USE_VERSION_9
bool
 
 config GCC_VERSION_9
---

Question is, do we really want to go down that route? Or is there
a better solution? Because this is ugly.

Regards,
Christian



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

Re: [OpenWrt-Devel] [PATCH] ramips: add support for ASUS RT-AC57U

[David Bauer]

Hello Christian,

On 24.06.19 21:19, Christian Lamparter wrote:

On Monday, June 24, 2019 2:31:57 PM CEST David Bauer wrote:

Some comments below.


diff --git a/target/linux/ramips/dts/RT-AC57U.dts 
b/target/linux/ramips/dts/RT-AC57U.dts
--- /dev/null
+++ b/target/linux/ramips/dts/RT-AC57U.dts
@@ -0,0 +1,150 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7621.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "asus,rt-ac57u", "ralink,mt7620a-soc";

"mediatek,mt7621-soc" ?


Whoops, you are right.  I will change this to

"mediatek,mt7621-soc"


(From what I know, the machine compatible isn't important
but the ralink,mt7620a-soc looks odd)


+   model = "ASUS RT-AC57U";
+
+   aliases {
+   led-boot = _power;
+   led-failsafe = _power;
+   led-running = _power;
+   led-upgrade = _power;
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x800>;
+   };
+
+   chosen {
+   bootargs = "console=ttyS0,57600";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   led_power: power {
+   label = "rt-ac57u:blue:power";
+   gpios = < 16 GPIO_ACTIVE_LOW>;
+   };
+
+   usb {
+   label = "rt-ac57u:blue:usb";
+   gpios = < 15 GPIO_ACTIVE_LOW>;
+   trigger-sources = <_port2>;
+   linux,default-trigger = "usbport";
+   };
+   };
+
+   keys {
+   compatible = "gpio-keys-polled";

The MT7261 should support interrupt-supported gpio-keys.


I will try your suggestion, however i suspect we will face the same 
issues we have on the ath79 platform currently.


While we are at it - i haven't forgotten about this one but due to 
hardware issues, testing is currently a bit cumbersome.





+   poll-interval = <20>;
+
+   wps {
+   label = "wps";
+   gpios = < 11 GPIO_ACTIVE_HIGH>;
+   linux,code = ;
+   };
+
+   reset {
+   label = "reset";
+   gpios = < 9 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+   };
+
+   led-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "LED-Power";
+   gpio = < 14 GPIO_ACTIVE_LOW>;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;

Just curious, is this regulator related to ASUS "Night mode"
feature? Also did you measure the voltages or is there a
3v3 LED driver on the board?


I suppose it is as the PHY LEDs seem to be controlled in hardware and so 
can't be toggled from software. The voltage is the one that goes to the 
LEDs.


Thinking about this, do you think we are better off using a "fake" LED 
for this that we set default on? A user is then able to turn off even 
the LEDs we can't control in software. We could name it something like 
"rt-ac57u:power:led". However, this would violate the naming scheme.


What do you think?




+   };
+};
+
+ {
+   status = "okay";
+
+   flash@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <1000>;

I haven't said much about the spi-max-frequencies before
but from what I know thanks to the threads like
"ramips: Increase GB-PC1 SPI frequency to 80MHz" the original
these values are off. And once the target switches to 4.19 (and
uses the upstream mt7621a.dtsi + spi-driver) this needs to be
reworked on all devices I think


I just head a quick look over this thread and the driver. I might be 
missing something, but shouldn't the spi bus run with 10 MHz in this case?


I don't doubt that we might be able to run higher frequencies, but the 
issue you pointed out in the thread seems to only apply to frequencies > 
25MHz.


Shall i test if the device runs with the current max of 25MHz and change 
the frequency accordingly?





+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "u-boot";
+   reg = <0x0 0x3>;
+   read-only;
+   };
+
+   partition@3 {
+   label = "config";
+   reg = <0x3 0x1>;
+   read-only;
+   };
+
+   factory: partition@4 {
+   label = "factory";
+   reg = <0x4 0x1>;
+  

Re: [OpenWrt-Devel] [PATCH] ramips: add support for ASUS RT-AC57U

[Christian Lamparter]

On Monday, June 24, 2019 2:31:57 PM CEST David Bauer wrote:

Some comments below.

> diff --git a/target/linux/ramips/dts/RT-AC57U.dts 
> b/target/linux/ramips/dts/RT-AC57U.dts
> --- /dev/null
> +++ b/target/linux/ramips/dts/RT-AC57U.dts
> @@ -0,0 +1,150 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +/dts-v1/;
> +
> +#include "mt7621.dtsi"
> +
> +#include 
> +#include 
> +
> +/ {
> + compatible = "asus,rt-ac57u", "ralink,mt7620a-soc";
"mediatek,mt7621-soc" ?
(From what I know, the machine compatible isn't important
but the ralink,mt7620a-soc looks odd)

> + model = "ASUS RT-AC57U";
> +
> + aliases {
> + led-boot = _power;
> + led-failsafe = _power;
> + led-running = _power;
> + led-upgrade = _power;
> + };
> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x800>;
> + };
> +
> + chosen {
> + bootargs = "console=ttyS0,57600";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_power: power {
> + label = "rt-ac57u:blue:power";
> + gpios = < 16 GPIO_ACTIVE_LOW>;
> + };
> +
> + usb {
> + label = "rt-ac57u:blue:usb";
> + gpios = < 15 GPIO_ACTIVE_LOW>;
> + trigger-sources = <_port2>;
> + linux,default-trigger = "usbport";
> + };
> + };
> +
> + keys {
> + compatible = "gpio-keys-polled";
The MT7261 should support interrupt-supported gpio-keys.

> + poll-interval = <20>;
> +
> + wps {
> + label = "wps";
> + gpios = < 11 GPIO_ACTIVE_HIGH>;
> + linux,code = ;
> + };
> +
> + reset {
> + label = "reset";
> + gpios = < 9 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +
> + led-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "LED-Power";
> + gpio = < 14 GPIO_ACTIVE_LOW>;
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-always-on;
Just curious, is this regulator related to ASUS "Night mode"
feature? Also did you measure the voltages or is there a
3v3 LED driver on the board?

> + };
> +};
> +
> + {
> + status = "okay";
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <1000>;
I haven't said much about the spi-max-frequencies before
but from what I know thanks to the threads like
"ramips: Increase GB-PC1 SPI frequency to 80MHz" the original
these values are off. And once the target switches to 4.19 (and
uses the upstream mt7621a.dtsi + spi-driver) this needs to be
reworked on all devices I think

> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "u-boot";
> + reg = <0x0 0x3>;
> + read-only;
> + };
> +
> + partition@3 {
> + label = "config";
> + reg = <0x3 0x1>;
> + read-only;
> + };
> +
> + factory: partition@4 {
> + label = "factory";
> + reg = <0x4 0x1>;
> + read-only;
> + };
> +
> + partition@5 {
> + compatible = "denx,uimage";
> + label = "firmware";
> + reg = <0x5 0xfb>;
> + };
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + wifi@0,0 {
> + reg = <0x 0 0 0 0>;
Please add a compatible. (Binding text lists the right one).

> + mediatek,mtd-eeprom = < 0x8000>;
> +
> + led {
> + led-sources = <2>;
> + led-active-low;
> + };
> + };
> +};
> +
> + {
> + wifi@0,0 {
> + reg = <0x 0 0 0 0>;
Please add a compatible. (Binding text lists the right one).
> + mediatek,mtd-eeprom = < 0x>;
> +
> + led {
> + led-active-low;
> + };
> + };
> +};
> +
> + {
> + mtd-mac-address = < 0x4e000>;
> +};
> +
> + {
> + state_default: pinctrl0 {
> + gpio {
> + ralink,group = "sdhci";
> + ralink,function = 

Re: [OpenWrt-Devel] ath10k-ct crash Archer C7 v2 - OpenWrt r10307-629e6538a1 - k4.19

[Ben Greear]

On 6/23/19 3:33 AM, Kevin 'ldir' Darbyshire-Bryant wrote:

Unfortunately flyspray won’t let me create a task, so filing this here so it 
doesn’t get lost.


Archer C7 v2 - OpenWrt r10307-629e6538a1 - k4.19

Recently seen the following firmware crashes on the device.  Seems to be 
related to my macbook coming out of power save mode.
There's been a recent ath10k-ct firmware bump so unclear if this is a wireless 
firmware bug or a kernel driver bug, or both.  Maybe the crashlog holds a clue.


Hello,

Does this seem to be a regression, or it never worked well, or you just started 
testing
this type of scenario?

Thanks,
Ben



[76300.806621] ath10k_pci :00:00.0: firmware crashed! (guid n/a)
[76300.812839] ath10k_pci :00:00.0: qca988x hw2.0 target 0x4100016c chip_id 
0x043202ff sub :
[76300.822239] ath10k_pci :00:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 
1 testmode 0
[76300.834379] ath10k_pci :00:00.0: firmware ver 
10.1-ct-8x-__fH-022-8f2afb9e api 2 features 
wmi-10.x,mfp,txstatus-noack,wmi-10.x-CT,ratemask-CT,regdump-CT,txrate-CT,flush-all-CT,pingpong-CT,ch-regs-CT,nop-CT,set-special-CT,get-temp-CT,tx-rc-CT,cust-stats-CT,retry-gt2-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT
 crc32 98d412c4
[76300.863764] ath10k_pci :00:00.0: board_file api 1 bmi_id N/A crc32 
bebc7c08
[76300.871195] ath10k_pci :00:00.0: htt-ver 2.2 wmi-op 2 htt-op 2 cal file 
max-sta 128 raw 0 hwcrypto 1
[76300.882843] ath10k_pci :00:00.0: firmware register dump:
[76300.888598] ath10k_pci :00:00.0: [00]: 0x4100016C 0x 0x009963E5 
0x
[76300.896637] ath10k_pci :00:00.0: [04]: 0x 0x00060324 0x 
0x
[76300.904670] ath10k_pci :00:00.0: [08]: 0x 0x 0x 
0x
[76300.912706] ath10k_pci :00:00.0: [12]: 0x0005 0x 0x 
0x
[76300.920750] ath10k_pci :00:00.0: [16]: 0x009B8BAB 0x0094085D 0x 
0x009963E5
[76300.928793] ath10k_pci :00:00.0: [20]: 0x809430B8 0x00401A40 0x0001 
0x0002
[76300.936837] ath10k_pci :00:00.0: [24]: 0x80940975 0x00401A60 0x001F 
0x00403BEC
[76300.944869] ath10k_pci :00:00.0: [28]: 0x409406B9 0x00401A80 0x001F 
0x000F
[76300.952905] ath10k_pci :00:00.0: [32]: 0x 0x00401AA0 0x00050024 
0x0403
[76300.960953] ath10k_pci :00:00.0: [36]: 0x 0x 0x 
0x
[76300.968991] ath10k_pci :00:00.0: [40]: 0x 0x 0x 
0x
[76300.977034] ath10k_pci :00:00.0: [44]: 0x 0x 0x 
0x
[76300.985066] ath10k_pci :00:00.0: [48]: 0x 0x 0x 
0x
[76300.993103] ath10k_pci :00:00.0: [52]: 0x 0x 0x 
0x
[76301.001146] ath10k_pci :00:00.0: [56]: 0x 0x 0x 
0x
[76301.009186] ath10k_pci :00:00.0: Copy Engine register dump:
[76301.015196] ath10k_pci :00:00.0: [00]: 0x00057400  14  14   3   3
[76301.021745] ath10k_pci :00:00.0: [01]: 0x00057800  20  20  54  55
[76301.028291] ath10k_pci :00:00.0: [02]: 0x00057c00  21  21  84  85
[76301.034826] ath10k_pci :00:00.0: [03]: 0x00058000  28  28  30  28
[76301.041378] ath10k_pci :00:00.0: [04]: 0x00058400 5087 5087  25 241
[76301.048100] ath10k_pci :00:00.0: [05]: 0x00058800   6   6 101 102
[76301.054636] ath10k_pci :00:00.0: [06]: 0x00058c00  22  22  22  22
[76301.061186] ath10k_pci :00:00.0: [07]: 0x00059000   0   0   0   0
[76301.069742] ath10k_pci :00:00.0: debug log header, dbuf: 0x412708  
dropped: 0
[76301.078358] ath10k_pci :00:00.0: [0] next: 0x412720 buf: 0x41056c sz: 
1500 len: 52 count: 2 free: 0
[76301.088905] ath10k_pci :00:00.0: ath10k_pci ATH10K_DBG_BUFFER:
[76301.095175] ath10k: []: 184AA804 0600FC13 1091   
0808 184AA804 0100FC17
[76301.104362] ath10k: [0008]:   30194000 6C010041 
[76301.68] ath10k_pci :00:00.0: ATH10K_END
[76301.116785] ath10k_pci :00:00.0: [1] next: 0x412708 buf: 0x410b5c sz: 
1500 len: 0 count: 0 free: 0
[76301.129238] ath10k_pci :00:00.0: removing peer, cleanup-all, deleting: 
peer 1e425dff vdev: 0 addr: 8c:85:90:36:ea:10
[76301.140415] ath10k_pci :00:00.0: removing peer, cleanup-all, deleting: 
peer 29f27609 vdev: 0 addr: 08:e6:89:40:12:7e
[76301.151549] ath10k_pci :00:00.0: removing peer, cleanup-all, deleting: 
peer 7cbbd9a3 vdev: 0 addr: c4:61:8b:23:6d:ca
[76301.162681] ath10k_pci :00:00.0: removing peer, cleanup-all, deleting: 
peer 15825a2b vdev: 0 addr: c8:f6:50:68:97:e5
[76301.173808] ath10k_pci :00:00.0: removing peer, cleanup-all, deleting: 
peer 8f0f5636 vdev: 0 addr: 14:cc:20:be:89:31
[76301.349424] ieee80211 phy0: Hardware restart was requested
[76302.616934] ath10k_pci :00:00.0: 10.1 wmi init: vdevs: 16  peers: 127  
tid: 256
[76302.634435] ath10k_pci :00:00.0: wmi print 'P 128 V 8 T 410'
[76302.640835] ath10k_pci :00:00.0: 

[OpenWrt-Devel] [PATCH] ramips: mt7621: Add new device AsiaRF AP7621-001

[Daniel Danzberger]

SoC:Mediatek MT7621A
CPU:4x 880Mhz
Cache:  32 KB I-Cache and 32 KB D-Cach
256 KB L2 Cache (shared by Dual-Core)
RAM:DDR3 512MB 16bits BUS
FLASH:  16MB
Switch: Mediatek Gigabit Switch (1 x LAN, 1 x WAN)
USB:1x 3.0
PCI:3x Mini PCIe
GPS:Quectel L70B
BTN:Reset
LED:- Power
- Ethernet
- Wifi
- USB
UART:  UART is present as Pads with throughholes on the PCB.
   They are located on left side.
   3.3V - RX - GND - TX / 57600-8N1
   3.3V is the square pad

Installation

The stock image is a modified openwrt and can be overflashed via sysupgrade 
-F

Signed-off-by: Daniel Danzberger 
---
 .../ramips/base-files/etc/board.d/02_network  |   3 +
 target/linux/ramips/dts/AP7621-001.dts| 127 ++
 target/linux/ramips/image/mt7621.mk   |  10 ++
 3 files changed, 140 insertions(+)
 create mode 100644 target/linux/ramips/dts/AP7621-001.dts

diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index 52204eacbf..ffd1689263 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -39,6 +39,9 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "4:wan:5" 
"6@eth0"
;;
+   asiarf,ap7621-001)
+   ucidef_add_switch "switch0" "0:lan" "4:wan" "6@eth0"
+   ;;
3g150b|\
3g300m|\
a5-v11|\
diff --git a/target/linux/ramips/dts/AP7621-001.dts 
b/target/linux/ramips/dts/AP7621-001.dts
new file mode 100644
index 00..daab06ec90
--- /dev/null
+++ b/target/linux/ramips/dts/AP7621-001.dts
@@ -0,0 +1,127 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+/dts-v1/;
+#include "mt7621.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "asiarf,ap7621-001", "mediatek,mt7621-soc";
+   model = "AP7621-001";
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x1c00>, <0x2000 0x400>;
+   };
+
+   chosen {
+   bootargs = "console=ttyS0,57600";
+   };
+
+   keys {
+   compatible = "gpio-keys";
+
+   reset {
+   label = "reset";
+   gpios = < 18 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   wlan1 {
+   label = "ap7621-001:orange:wlan1";
+   gpios = < 11 GPIO_ACTIVE_LOW>;
+   };
+
+   wlan0 {
+   label = "ap7621-001:orange:wlan0";
+   gpios = < 12 GPIO_ACTIVE_LOW>;
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+status = "okay";
+
+flash@0 {
+compatible = "jedec,spi-nor";
+reg = <0>;
+spi-max-frequency = <4000>;
+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "u-boot";
+   reg = <0x0 0x3>;
+   read-only;
+   };
+
+   partition@3 {
+   label = "u-boot-env";
+   reg = <0x3 0x2000>;
+   };
+
+   partition@32000 {
+   label = "2860";
+   reg = <0x32000 0x4000>;
+   };
+
+   partition@36000 {
+   label = "rtdev";
+   reg = <0x36000 0x2000>;
+   };
+
+   partition@38000 {
+   label = "Reserve";
+   reg = <0x38000 0x8000>;
+   };
+
+   factory: partition@4 {
+   label = "factory";
+   reg = <0x4 0x1>;
+   read-only;
+   };
+
+   firmware: partition@5 {
+   label = "firmware";
+   reg = <0x5 0xfa>;
+   compatible = "denx,uimage";
+   };
+
+   partition@ff {
+   label = "nvram";
+   reg = <0xff 0x1>;
+   };
+   };
+};
+};
+
+ {
+   

Re: [OpenWrt-Devel] sysupgrade: extending firmware validation

[Rafał Miłecki]

On 19.06.2019 16:07, Rafał Miłecki wrote:

My question is: what do you find the best way of implementing it?


Today IRC chat log for a reference:

[12:21]  guys, would you check my "sysupgrade: extending firmware 
validation" e-mail?
[12:21]  jow: that possibly affects LuCI
[12:21]  blogic: you like designing things, maybe check that one?
[12:23]  rmilecki: lets have a look right now
[12:25]  rmilecki: sysupgrade is already triggered from procd
[12:26]  so the sysupgrade shell foo could gain a helper that you pass 
a result which gets sent out to procd via ubus
[12:26]  the flash process would need to be split into check and flash
[12:26]  ad procd would call them separatley
[12:26] * rmilecki is thinking
[12:26]  and if the first return !0 then it just does not start 2/ramfs 
and waits for the result json
[12:27]  and when the result json is there we could provide it on ubus
[12:27]  that way you can throw anything into the json, procd would 
just memcpy the blob and have a sysupgrade.status or similar ubus method
[12:27]  as for signing 
[12:27]  doesn't sysupgrade already have a check only 
command/option?
[12:28]  sysupgrade -T /tmp/foo.img
[12:28]  KanjiMonster: it does but not via ubus/procd i think
[12:28]  it's 0/1 result
[12:28]  KanjiMonster: it requires the luci-helper thingy
[12:31]  sorry, i'll need more explaning there, starting with the: "so the 
sysupgrade shell foo could gain a helper that you pass a result which gets sent out to procd 
via ubus"
[12:31]  do you want a a new call like "/sbin/sysupgrade foo /tmp/file" that 
calls "ubus call procd something"?
[12:35]   /sbin/sysupgrade needs a new function inside that gets called 
from the platform_check_image()
[12:37]  and that new function should call ubus? or print JSON?
[12:39]  sysupgrae_check_result() or whatever that send the reason via 
ubus to procd
[12:39]  so that each target can be upgraded to this new image check 
code
[12:39]  if the check_image fails the target just calls that helper
[12:39]  and procd puts the result into ubus as a call the webui can do
[12:41]  ok, I think I got the idea, thanks!
[12:42]  i'll try to implement it piece by piece and see how it goes

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

[OpenWrt-Devel] [openwrt] Patch notification: 1 patch updated

[Patchwork]

Hello,

The following patch (submitted by you) has been updated in Patchwork:

 * openwrt: [OpenWrt-Devel,v2,1/1] ustream-ssl: mbedtls: use chacha-poly 
ciphersuites
 - http://patchwork.ozlabs.org/patch/952204/
 - for: OpenWrt development
was: New
now: Accepted

This email is a notification only - you do not need to respond.

Happy patchworking.

--

This is an automated mail sent by the Patchwork system at
patchwork.ozlabs.org. To stop receiving these notifications, edit
your mail settings at:
  http://patchwork.ozlabs.org/mail/

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

[OpenWrt-Devel] [PATCH] ramips: add support for ASUS RT-AC57U

[David Bauer]

SoC:   MediaTek MT7621AT
RAM:   128M (Winbond W631GG6KB-15)
FLASH: 16MB (Spansion S25FL128SA)
WiFi:  MediaTek MT7603EN bgn 2SS
WiFi:  MediaTek MT7612EN nac 2SS
BTN:   Reset - WPS
LED:- Power
- LAN {1-4}
- WAN
- WiFi 2.4 GHz
- WiFi 5 GHz
- USB
UART:  UART is present next to the Power LED.
   TX - RX - GND - 3V3 / 57600-8N1
   3V3 is the nearest one to the Power LED.

Installation

Via TFTP:
1. Set your computers IP-Address to 192.168.1.75.
2. Power up the Router with the Reset button pressed.
3. Release the Reset button after 5 seconds.
4. Upload OpenWRT sysupgrade image via TFTP:
 > tftp -4 -v -m binary 192.168.1.1 -c put 

Via SSH:
Note: User/password for SSH is identical with the one used in the
Web-interface.
1. Complete the initial setup wizard.
2. Activate SSH under "Administration" -> "System".
3. Transfer the OpenWrt sysupgrade image via scp:
 > scp owrt.bin admin@192.168.1.1:/tmp
4. Connect via SSH to the router.
 > ssh admin@192.168.1.1
5. Write the OpenWrt image to flash.
 > mtd-write -i /tmp/owrt.bin -d linux
6. Reboot the router
 > reboot

Signed-off-by: David Bauer 
---
 .../ramips/base-files/etc/board.d/02_network  |  10 +-
 target/linux/ramips/dts/RT-AC57U.dts  | 150 ++
 target/linux/ramips/image/mt7621.mk   |   8 +
 3 files changed, 164 insertions(+), 4 deletions(-)
 create mode 100644 target/linux/ramips/dts/RT-AC57U.dts

diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index 52204eacbf..1efbbf586e 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -215,6 +215,7 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"1:lan" "2:lan" "3:lan" "4:lan" "6t@eth0"
;;
+   asus,rt-ac57u|\
atp-52b|\
awm002-evb-4M|\
awm002-evb-8M|\
@@ -497,6 +498,11 @@ ramips_setup_macs()
wmdr-143n)
lan_mac=$(cat /sys/class/net/eth0/address)
;;
+   asus,rt-ac57u|\
+   vr500)
+   lan_mac=$(mtd_get_mac_binary factory 57344)
+   wan_mac=$(mtd_get_mac_binary factory 57350)
+   ;;
carambola|\
freestation5|\
w502u|\
@@ -649,10 +655,6 @@ ramips_setup_macs()
lan_mac=$(mtd_get_mac_ascii u-boot-env LAN_MAC_ADDR)
wan_mac=$(mtd_get_mac_ascii u-boot-env WAN_MAC_ADDR)
;;
-   vr500)
-   lan_mac=$(mtd_get_mac_binary factory 57344)
-   wan_mac=$(mtd_get_mac_binary factory 57350)
-   ;;
w306r-v20)
lan_mac=$(cat /sys/class/net/eth0/address)
wan_mac=$(macaddr_add "$lan_mac" 5)
diff --git a/target/linux/ramips/dts/RT-AC57U.dts 
b/target/linux/ramips/dts/RT-AC57U.dts
new file mode 100644
index 00..c9eb2a5223
--- /dev/null
+++ b/target/linux/ramips/dts/RT-AC57U.dts
@@ -0,0 +1,150 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7621.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "asus,rt-ac57u", "ralink,mt7620a-soc";
+   model = "ASUS RT-AC57U";
+
+   aliases {
+   led-boot = _power;
+   led-failsafe = _power;
+   led-running = _power;
+   led-upgrade = _power;
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x800>;
+   };
+
+   chosen {
+   bootargs = "console=ttyS0,57600";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   led_power: power {
+   label = "rt-ac57u:blue:power";
+   gpios = < 16 GPIO_ACTIVE_LOW>;
+   };
+
+   usb {
+   label = "rt-ac57u:blue:usb";
+   gpios = < 15 GPIO_ACTIVE_LOW>;
+   trigger-sources = <_port2>;
+   linux,default-trigger = "usbport";
+   };
+   };
+
+   keys {
+   compatible = "gpio-keys-polled";
+   poll-interval = <20>;
+
+   wps {
+   label = "wps";
+   gpios = < 11 GPIO_ACTIVE_HIGH>;
+   linux,code = ;
+   };
+
+   reset {
+   label = "reset";
+   gpios = < 9 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+   };
+
+   led-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "LED-Power";
+   gpio = < 14 GPIO_ACTIVE_LOW>;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   };
+};
+
+ {
+   status = "okay";
+
+   

Re: [OpenWrt-Devel] [PATCH] ramips: mt7621: Add new device AsiaRF AP7621-001

[Daniel Danzberger]

hi,

Once I add in  'ralink,group = "uart2", "wdt";', I get the following errors and
the flash isn't going to be initialized.
---
[2.823681] mt7621-pci 1e14.pcie: could not find pctldev for node
/pinctrl/pcie, deferring probe
[2.842075] spi-mt7621 1e000b00.spi: could not find pctldev for node
/pinctrl/spi_pins, deferring probe
---

The flash works fine with 40Mhz.
I also removed the pcie0/1 wlan nodes, hence the board comes with plain PCIE
slots without any wifi attached.


On 6/22/19 4:46 AM, Chuanhong Guo wrote:
> Hi!
> 
> Some comments inline :)
> 
> On Fri, Jun 21, 2019 at 11:50 PM Daniel Danzberger  wrote:
>>
>> Signed-off-by: Daniel Danzberger 
> 
> When adding new device support, commit message should include a brief
> description of the hardware and an installation guide.
> You could check recent commits [1] for some examples.
> 
>> ---
>>  .../ramips/base-files/etc/board.d/02_network  |   5 +
>>  target/linux/ramips/base-files/lib/ramips.sh  |   3 +
>>  target/linux/ramips/dts/AP7621-001.dts| 157 ++
>>  target/linux/ramips/image/mt7621.mk   |  12 ++
>>  target/linux/ramips/mt7621/config-4.14|   1 +
>>  5 files changed, 178 insertions(+)
>>  create mode 100644 target/linux/ramips/dts/AP7621-001.dts
>>
>> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
>> b/target/linux/ramips/base-files/etc/board.d/02_network
>> index 52204eacbf..ee0c23eeb5 100755
>> --- a/target/linux/ramips/base-files/etc/board.d/02_network
>> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
>> @@ -39,6 +39,11 @@ ramips_setup_interfaces()
>> ucidef_add_switch "switch0" \
>> "0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "4:wan:5" 
>> "6@eth0"
>> ;;
>> +   ap7621-001)
>> +   ucidef_set_interfaces_lan_wan "eth0.1" "eth0.2"
> 
> There is no need to explicitly define lan and wan interfaces here.
> This will be handled by ucidef_add_switch.
> 
>> +   ucidef_set_interfaces relay ifname "'wwan' 'lan'" protocol 
>> relay
>> +   ucidef_add_switch "switch0" "0:lan" "4:wan" "6@eth0"
>> +   ;;
>> 3g150b|\
>> 3g300m|\
>> a5-v11|\
>> diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
>> b/target/linux/ramips/base-files/lib/ramips.sh
>> index 093303892c..2350e88354 100755
>> --- a/target/linux/ramips/base-files/lib/ramips.sh
>> +++ b/target/linux/ramips/base-files/lib/ramips.sh
>> @@ -46,6 +46,9 @@ ramips_board_detect() {
>> *"ALL5003")
>> name="all5003"
>> ;;
>> +   *"AP7621-001")
>> +   name="ap7621-001"
>> +   ;;
> 
> This board detection is deprecated.
> The first compatible string will be used as board name if an entry
> isn't added here.
> 
>> *"AR670W")
>> name="ar670w"
>> ;;
>> diff --git a/target/linux/ramips/dts/AP7621-001.dts 
>> b/target/linux/ramips/dts/AP7621-001.dts
>> new file mode 100644
>> index 00..587c26457e
>> --- /dev/null
>> +++ b/target/linux/ramips/dts/AP7621-001.dts
>> @@ -0,0 +1,157 @@
>> +/dts-v1/;
>> +#include "mt7621.dtsi"
>> +
>> +#include 
>> +#include 
>> +
>> +/ {
>> +   compatible = "asiarf,ap7621-001", "mediatek,mt7621-soc";
>> +   model = "AP7621-001";
>> +
>> +   memory@0 {
>> +   device_type = "memory";
>> +   reg = <0x0 0x1c00>, <0x2000 0x400>;
>> +   };
>> +
>> +   chosen {
>> +   bootargs = "console=ttyS0,57600";
>> +   };
>> +
>> +   palmbus: palmbus@1E00 {
>> +   i2c@900 {
>> +   status = "okay";
>> +   };
>> +   };
> 
> What is i2c used for? If there isn't something already connected on
> board, it should be disabled.
> 
>> +
>> +   gpio-keys-polled {
> 
> Rename this one to "keys" according to Generic Names Recommendation in
> device tree specification. [2]
> 
>> +   compatible = "gpio-keys-polled";
> 
> Interrupt based gpio-keys can be used here instead of gpio-keys-polled.
> 
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +   poll-interval = <20>;
>> +
>> +   reset {
>> +   label = "reset";
>> +   gpios = < 18 GPIO_ACTIVE_LOW>;
>> +   linux,code = ;
>> +   };
>> +   };
>> +
>> +   gpio-leds {
> 
> This should be renamed to "leds".
> 
>> +   compatible = "gpio-leds";
>> +
>> +   wlan1 {
>> +   label = "ap7621-001:orange:wlan1";
>> +   gpios = < 11 GPIO_ACTIVE_LOW>;
>> +   };
>> +   };
>> +
>> +   gpio-leds {
>> +   compatible = "gpio-leds";
> 
> gpio-leds supports multiple leds in the same platform device and there
> is no need to create a second "leds" node here.
> Just drop the above 4 lines so 

[OpenWrt-Devel] [PATCH] ath79: add support for gl-ar750

[Luochongjun]

This patch support gl-ar750 on ath79.

Signed-off-by: Luo chongjun 
---
 .../etc/hotplug.d/firmware/11-ath10k-caldata   |   1 +
 target/linux/ath79/dts/qca9531_glinet_gl-ar750.dts | 149 +
 target/linux/ath79/image/generic.mk|   8 ++
 3 files changed, 158 insertions(+)
 create mode 100644 target/linux/ath79/dts/qca9531_glinet_gl-ar750.dts

diff --git 
a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata 
b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 8f0ea1d..6a9cb1c 100644
--- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -116,6 +116,7 @@ case "$FIRMWARE" in
ath10kcal_extract "art" 20480 2116
ath10kcal_patch_mac $(macaddr_add $(cat 
/sys/class/net/eth0/address) +1)
;;
+   glinet,gl-ar750|\
glinet,gl-ar750s)
ath10kcal_extract "art" 20480 2116
ath10kcal_patch_mac $(macaddr_add $(mtd_get_mac_binary art 0) 
+1)
diff --git a/target/linux/ath79/dts/qca9531_glinet_gl-ar750.dts 
b/target/linux/ath79/dts/qca9531_glinet_gl-ar750.dts
new file mode 100644
index 000..c173f0d
--- /dev/null
+++ b/target/linux/ath79/dts/qca9531_glinet_gl-ar750.dts
@@ -0,0 +1,149 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include 
+#include 
+
+#include "qca953x.dtsi"
+
+/ {
+   compatible = "glinet,gl-ar750", "qca,qca9531";
+   model = "GL.iNet GL-AR750";
+
+   keys {
+   compatible = "gpio-keys-polled";
+
+   poll-interval = <20>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_disable_pins>;
+
+   reset {
+   label = "reset";
+   linux,code = ;
+   gpios = < 3 GPIO_ACTIVE_LOW>;
+   };
+
+   mode {
+label = "mode";
+linux,code = ;
+gpios = < 0 GPIO_ACTIVE_LOW>;
+};
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   power {
+   label = "gl-ar750:green:power";
+   gpios = < 12 GPIO_ACTIVE_LOW>;
+   default-state = "on";
+   };
+
+   wlan2g {
+   label = "gl-ar750:green:wlan2g";
+   gpios = < 14 GPIO_ACTIVE_LOW>;
+   linux,default-trigger = "phy1tpt";
+   };
+
+   wlan5g {
+   label = "gl-ar750:green:wlan5g";
+   gpios = < 13 GPIO_ACTIVE_LOW>;
+   linux,default-trigger = "phy0tpt";
+   };
+
+   };
+
+   i2c {
+compatible = "i2c-gpio";
+
+sda-gpios = < 17 GPIO_ACTIVE_LOW>;
+scl-gpios = < 16 GPIO_ACTIVE_LOW>;
+
+/* can be removed on 4.19 */
+gpios = < 17 GPIO_ACTIVE_LOW>,
+< 16 GPIO_ACTIVE_LOW>;
+
+};
+
+
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "okay";
+
+   hub_port: port@1 {
+   reg = <1>;
+   #trigger-source-cells = <0>;
+   };
+};
+
+_phy {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+   num-cs = <0>;
+
+   flash@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <2500>;
+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "u-boot";
+   reg = <0x00 0x04>;
+   read-only;
+   };
+
+   partition@4 {
+   label = "u-boot-env";
+   reg = <0x04 0x01>;
+   };
+
+   art: partition@5 {
+   label = "art";
+   reg = <0x05 0x01>;
+   read-only;
+   };
+
+   partition@6 {
+   compatible = "denx,uimage";
+   label = "firmware";
+   reg = <0x06 0xfa>;
+   };
+   };
+   };
+};
+
+ {
+   status = "okay";
+   mtd-mac-address = < 0x0>;
+   phy-handle = <>;
+};
+
+ {
+   mtd-mac-address = < 0x0>;
+   mtd-mac-address-increment = <1>;
+};
+
+ {
+   status = "okay";
+   mtd-cal-data =