Re: [OpenWrt-Devel] [PATCH] ath79: Add support for Ubiquity

2018-11-18 Thread Joe Ayers
testing update for Nanostation M5 XW:

indeed this entry is needed in 02_network:

ubnt,nano-m-xw)
ucidef_add_switch "switch0" \
"0@eth0" "5:lan" "1:wan"
;;

 On a laptop on the LAN, I observe frames egressing (arp requests) and
TX counts triggered by a ping on the device of a laptop IP address.
However, no frames are being received.  There were corresponding TX
packet counts with the ping, but always 0 count RX.

The wlan0 was not showing due to defaulted /etc/config/wireless with
"option disabled '1'".I changed this option to '0' and restarted
the network:


wlan0 Link encap:Ethernet  HWaddr 04:18:D6:A6:70:B5
  inet6 addr: fe80::618:d6ff:fea6:70b5/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:108 errors:0 dropped:0 overruns:0 frame:0
  TX packets:120 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:10987 (10.7 KiB)  TX bytes:16383 (15.9 KiB)

Success, I am able to connect to SSID "OpenWrt" and access the device via ssh.

___
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 Ubiquity Bullet M2HP

2018-11-18 Thread Petr Štetiar
Lech Perczak  [2018-11-18 21:34:53]:

> Can I add Tested-By tag to my patch? :)

Tested-by: Petr Štetiar  (tested on ar71xx/ath79 with 
bullet-m-xw)

-- ynezz

___
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 Ubiquity Bullet M2HP

2018-11-18 Thread Lech Perczak

Hello Petr,

W dniu 2018-11-18 o 21:18, Petr Štetiar pisze:

Lech Perczak  [2018-11-18 17:21:46]:


well as checking if rssileds package was indeed pulled in via "opkg list

Somehow the rssileds package wasn't enabled even if I've selected building of
nano-xm-w via menu config. I've deleted the .config and created a new one,
then it was selected, weird. Anyway it works also on ar71xx/bullet-m-xw.

-- ynezz


Big thanks for testing!
Can I add Tested-By tag to my patch? :)

--
Pozdrawiam,
Lech Perczak
lech.perc...@gmail.com
Mobile: +48 694 309 185


___
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 Ubiquity Bullet M2HP

2018-11-18 Thread Petr Štetiar
Lech Perczak  [2018-11-18 17:21:46]:

> well as checking if rssileds package was indeed pulled in via "opkg list

Somehow the rssileds package wasn't enabled even if I've selected building of
nano-xm-w via menu config. I've deleted the .config and created a new one,
then it was selected, weird. Anyway it works also on ar71xx/bullet-m-xw.

-- ynezz

___
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 Ubiquity

2018-11-18 Thread Joe Ayers
> I recall that ar71xx had a hack for freezing Ethernet ports on XW
> boards. This may need to be ported also. I need to dig into the sources
> for details.

This was all due to the unique architecture by Ubiquiti with an
external chip used and not the AR93xx onchip Ethernet.   In CC, the
8035 chip and gpio reset was added  in the 803x PHY driver-- which
handled the rockets and some other XW models. The loco XW and some
other devices used the 8032 PHY and never got addressed until LEDE
release.

See:  
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=106a4605c87c91dd71b09b2814e232ebac6873ed

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


Re: [OpenWrt-Devel] openwrt-devel Digest, Vol 31, Issue 40

2018-11-18 Thread Joe Ayers
> I recall that ar71xx had a hack for freezing Ethernet ports on XW
> boards. This may need to be ported also. I need to dig into the sources
> for details.

This was all due to the unique architecture by Ubiquiti with an
external chip used and not the AR93xx onchip Ethernet.   In CC, the
8035 chip and gpio reset was added  in the 803x PHY driver-- which
handled the rockets and some other XW models. The loco XW and some
other devices used the 8032 PHY and never got addressed until LEDE
release.

See:  
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=106a4605c87c91dd71b09b2814e232ebac6873ed

___
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 Ubiquity

2018-11-18 Thread Joe Ayers
> > root@AE6XE-NSM5XW-QTH:~# cat /etc/openwrt_version
> > r7258-5eb055306f
>
> I was asking for airOS version, so it should rather be `cat /etc/version`. I
> don't have /etc/openwrt_version in my airOS v6.1.7 system.
>

I was running openwrt 3.18.06.1 prior to tftp'ing this test image.  It
shouldn't make any difference what 'inert' bits are in these other
flash partitions.  We're overwriting the data with the bootloader (we
both have the same bootloader version) through the tftp process.  I
could reload airOS v6.1.7 and start with the same state if this would
address further concerns of the testing results?

On the serial console, could see why your node is not going into tftp
server mode or if other reason?

> > I applied this 002-firmware-check-fix.patch to your build referenced
> > above and tftp'd it to a NS M5 XW with "U-Boot 1.1.4-s1039 (May 24
> > 2017 - 15:58:18)" bootloader.  Looks like nano-m-xw is missing from
> > .../base-files/etc/board.d/02_network.   Consequently, the network
> > physical ports are non-functional and the wireless is not showing up.
>
> nano-m-xw missing in 02_network as it's probably standard eth0/eth1 setup so
> it would use the default:
>
>  *)
> ucidef_set_interfaces_lan_wan "eth0" "eth1"
> ;;
>

Reviewing the AR934x Data Sheet might give a better visual.   There
are 2 switch chips on this device (and other UBNT XW models).  For
whatever reason ubnt does not use the on-chip AR934x switch.  In dmesg
from the test image, we see this onchip-AR9342 switch at Gigabit MAC1:

mdio-bus.1:1f: Found an AR934X built-in switch  # showing up as
eth1, but this is not used.or dead end.  a way to undefine so it
doesn't show up?

The external switch chip is found here on the AR934X Gigabit MAC0:

switch0: Atheros AR8236 rev. 1 switch registered on mdio-bus.0   #
showing up as eth0 and the path to external ports
ag71xx 1900.eth: connected to PHY at mdio-bus.0:04 [uid=004dd043,
driver=Atheros AR8216/AR8236/AR8316]
The external ports are on this switch ports 1 and 5.

in 3.18.06.1, the 02_network definitions are like this and probably
need to roll forward:
nanostation-m-xw)
ucidef_add_switch "switch0" \
"0@eth0" "5:lan" "1:wan"
;;

It's also a bit tricky as there is a GPIO pin for reset from the
AR934X over to the AR8236 (and AR803x chips on other XW hardware) too.
I'm not that familiar with device tree yet, but I suspect this detail
needs defined as well.

Joe

___
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 Ubiquity Bullet M2HP

2018-11-18 Thread Lech Perczak

Hi Petr,

Thanks for testing!

W dniu 2018-11-18 o 17:05, Petr Štetiar pisze:

Lech Perczak  [2018-11-18 01:29:08]:

Hi,


Actually, I meant building and testing on ar71xx target instead of ath79.
But anyway, you might include this little change in your patch,
because when I added this support, XW wasn't ported to ath79 yet. Therefore
the LED configuration didn't need any alterations, as on ath79 it doesn't
specify PWM support.

I've just pulled your changes into my testing branch so it looks like this now:

  07b41e3 Merge commit 'refs/pull/1372/head' of 
https://github.com/openwrt/openwrt into nanostation-m-xw
  a49e6d0 ar71xx: ubnt-(xm,xw): add rssileds package
  78c3af2 ar71xx: ubnt-(xm,xw): create RSSI monitor on wlan0
  bc95553 ath79: ubnt-xw: Add rssileds kernel package
  ffc74ff WIP: ath79: Add support for Ubiquiti Nanostation M (XW)
  67a8871 ath79: Add support for Ubiquity Bullet M (XW)
  dd02a19 ar71xx: fix TP-Link Archer C7 v5 switch LEDs
  251c350 mt76: update to the latest version

Then I've built ar71xx image for nano-m-xw, but it seems like this image
doesn't work out of the box on bullet-m-xw, the green/link4 is on after boot,
and RSSI LEDs doesn't work as on ath79. Setting timer tigger on the LEDs
manually works. Don't have time right now to find out what's the problem, any
idea where should I look at?

-- ynezz

A dump of /etc/config/system right after first  boot might be useful, as 
well as checking if rssileds package was indeed pulled in via "opkg list 
--installed | grep rssileds" . Maybe .config needs to be refreshed. At 
least on XM it worked for me :)


--
Pozdrawiam,
Lech Perczak
lech.perc...@gmail.com
Mobile: +48 694 309 185


___
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 Ubiquity Bullet M2HP

2018-11-18 Thread Petr Štetiar
Lech Perczak  [2018-11-18 01:29:08]:

Hi,

> Actually, I meant building and testing on ar71xx target instead of ath79.
> But anyway, you might include this little change in your patch,
> because when I added this support, XW wasn't ported to ath79 yet. Therefore
> the LED configuration didn't need any alterations, as on ath79 it doesn't
> specify PWM support.

I've just pulled your changes into my testing branch so it looks like this now:

 07b41e3 Merge commit 'refs/pull/1372/head' of 
https://github.com/openwrt/openwrt into nanostation-m-xw
 a49e6d0 ar71xx: ubnt-(xm,xw): add rssileds package
 78c3af2 ar71xx: ubnt-(xm,xw): create RSSI monitor on wlan0
 bc95553 ath79: ubnt-xw: Add rssileds kernel package
 ffc74ff WIP: ath79: Add support for Ubiquiti Nanostation M (XW)
 67a8871 ath79: Add support for Ubiquity Bullet M (XW)
 dd02a19 ar71xx: fix TP-Link Archer C7 v5 switch LEDs
 251c350 mt76: update to the latest version

Then I've built ar71xx image for nano-m-xw, but it seems like this image
doesn't work out of the box on bullet-m-xw, the green/link4 is on after boot,
and RSSI LEDs doesn't work as on ath79. Setting timer tigger on the LEDs
manually works. Don't have time right now to find out what's the problem, any
idea where should I look at?

-- ynezz

___
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 Ubiquity

2018-11-18 Thread Lech Perczak

Hi Petr, Joe,

W dniu 2018-11-18 o 10:03, Petr Štetiar pisze:

Joe Ayers  [2018-11-17 18:40:56]:


Hm, I'm really wondering what version of airOS do you've on your devices, that
the TFTP recovery method works for you.

root@AE6XE-NSM5XW-QTH:~# cat /etc/openwrt_version
r7258-5eb055306f

I was asking for airOS version, so it should rather be `cat /etc/version`. I
don't have /etc/openwrt_version in my airOS v6.1.7 system.


I applied this 002-firmware-check-fix.patch to your build referenced
above and tftp'd it to a NS M5 XW with "U-Boot 1.1.4-s1039 (May 24
2017 - 15:58:18)" bootloader.  Looks like nano-m-xw is missing from
.../base-files/etc/board.d/02_network.   Consequently, the network
physical ports are non-functional and the wireless is not showing up.

nano-m-xw missing in 02_network as it's probably standard eth0/eth1 setup so
it would use the default:

  *)
 ucidef_set_interfaces_lan_wan "eth0" "eth1"
 ;;

This is indeed the case, also for XM.


>From the dmesg it seems like both eth0/eth1 devices are setup, but they
apparently doesn't work for you for some reason. Are at least the MAC
addresses correct?
I recall that ar71xx had a hack for freezing Ethernet ports on XW 
boards. This may need to be ported also. I need to dig into the sources 
for details. This is likely as according to Joe's kernel log both links 
are up and established actually, but nothing is received.


Don't know why the wifi interface wasn't autodetected. It seems like I might
have something wrong in my DTS, maybe something is missing in the generic code
somewhere.
This indeed seems like issue with device tree, as in kernel log I don't 
see the ath9k driver even probing the radio. In XM case it would at 
least complain about missing calibration data.


I'd also take a look at UBNT WA device tree, ath9k wmac is used there as 
2.4GHz-only management radio, and configuration looks very similar to yours.


You might also take a look at ar9344_tplink_tl-wdr4300.dtsi for more 
examples on configuration of ath9k driver via device tree.


Also, you might want to take a look at 
"target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom" - 
maybe you need to extract ath9k eeprom there. But this is when you 
actually get ath9k to at least start probing.





What other data would be helpful?

I would probably need to read the sources, add some debugging printfs and do a
few (maybe a lot) reboots to find out where the problem is.

I'll try to look at it more when I've some spare time, until then it will
probably need someone more experienced with this platform (Lech?) to tell us
what might be wrong here.

-- ynezz

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



--
Pozdrawiam,
Lech Perczak
lech.perc...@gmail.com
Mobile: +48 694 309 185


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


[OpenWrt-Devel] [PATCH] ramips: fix ethernet for f5d8235-v2 board

2018-11-18 Thread Roman Yeryomin
Belkin F5D8235 v2 has two ethernet switches on board.
One internal rt3052 and rtl8366rb on rgmii interface.
Looks like internal switch settings were lost in
translation to device tree infrastructure.

Signed-off-by: Roman Yeryomin 
---
 .../linux/ramips/base-files/etc/board.d/02_network  |  2 +-
 target/linux/ramips/dts/F5D8235_V2.dts  | 13 -
 target/linux/ramips/image/rt305x.mk |  1 +
 3 files changed, 14 insertions(+), 2 deletions(-)

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 9e9ecbcb51..7a6b4c76b4 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -200,7 +200,6 @@ ramips_setup_interfaces()
awm002-evb-8M|\
c20i|\
dir-645|\
-   f5d8235-v2|\
gl-mt300a|\
gl-mt300n|\
gl-mt750|\
@@ -371,6 +370,7 @@ ramips_setup_interfaces()
"0:lan" "2:lan" "6t@eth0"
;;
f5d8235-v1|\
+   f5d8235-v2|\
tew-714tru|\
v11st-fe|\
wzr-agl300nh)
diff --git a/target/linux/ramips/dts/F5D8235_V2.dts 
b/target/linux/ramips/dts/F5D8235_V2.dts
index a3a1255941..1a86557ca4 100644
--- a/target/linux/ramips/dts/F5D8235_V2.dts
+++ b/target/linux/ramips/dts/F5D8235_V2.dts
@@ -111,7 +111,7 @@
  {
state_default: pinctrl0 {
gpio {
-   ralink,group = "spi", "i2c", "jtag", "rgmii", "mdio", 
"uartf";
+   ralink,group = "spi", "i2c", "jtag", "mdio", "uartf";
ralink,function = "gpio";
};
};
@@ -119,10 +119,21 @@
 
  {
mtd-mac-address = < 0x40004>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
 };
 
  {
+   ralink,rgmii = <1>;
mediatek,portmap = <0x3f>;
+   ralink,fct2 = <0x0002500c>;
+   /*
+* ext phy base addr 31, rx/tx clock skew 0,
+* turbo mii off, rgmi 3.3v off, port 5 polling off
+* port5: enabled, gige, full-duplex, rx/tx-flow-control
+* port6: enabled, gige, full-duplex, rx/tx-flow-control
+   */
+   ralink,fpa2 = <0x1f003fff>;
 };
 
  {
diff --git a/target/linux/ramips/image/rt305x.mk 
b/target/linux/ramips/image/rt305x.mk
index 066cef23cb..cc743c609d 100644
--- a/target/linux/ramips/image/rt305x.mk
+++ b/target/linux/ramips/image/rt305x.mk
@@ -329,6 +329,7 @@ define Device/f5d8235-v2
   DTS := F5D8235_V2
   IMAGE_SIZE := 7744k
   DEVICE_TITLE := Belkin F5D8235 v2
+  DEVICE_PACKAGES := kmod-switch-rtl8366rb
 endef
 TARGET_DEVICES += f5d8235-v2
 
-- 
2.17.1


___
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 Ubiquity

2018-11-18 Thread Petr Štetiar
Joe Ayers  [2018-11-17 18:40:56]:

> > Hm, I'm really wondering what version of airOS do you've on your devices, 
> > that
> > the TFTP recovery method works for you.
> 
> root@AE6XE-NSM5XW-QTH:~# cat /etc/openwrt_version
> r7258-5eb055306f

I was asking for airOS version, so it should rather be `cat /etc/version`. I
don't have /etc/openwrt_version in my airOS v6.1.7 system.

> I applied this 002-firmware-check-fix.patch to your build referenced
> above and tftp'd it to a NS M5 XW with "U-Boot 1.1.4-s1039 (May 24
> 2017 - 15:58:18)" bootloader.  Looks like nano-m-xw is missing from
> .../base-files/etc/board.d/02_network.   Consequently, the network
> physical ports are non-functional and the wireless is not showing up.

nano-m-xw missing in 02_network as it's probably standard eth0/eth1 setup so
it would use the default:

 *)
ucidef_set_interfaces_lan_wan "eth0" "eth1"
;;

>From the dmesg it seems like both eth0/eth1 devices are setup, but they
apparently doesn't work for you for some reason. Are at least the MAC
addresses correct?

Don't know why the wifi interface wasn't autodetected. It seems like I might
have something wrong in my DTS, maybe something is missing in the generic code
somewhere.

> What other data would be helpful?

I would probably need to read the sources, add some debugging printfs and do a
few (maybe a lot) reboots to find out where the problem is.

I'll try to look at it more when I've some spare time, until then it will
probably need someone more experienced with this platform (Lech?) to tell us
what might be wrong here.

-- ynezz

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