Re: [OpenWrt-Devel] Is "using gpio to simulate I2C bus" robust on AR9331?

2017-05-04 Thread Gareth Parker
OpenWrt seems dead these days, active development is over at lede-project.

Also for i2c I would recommend using a PIC microcontroller, its far easier and 
designed for that purpose.  I use a PIC to control PLL IC's over i2c such as 
the TSA5511 in FM broadcast gear I design.

Gareth

-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf 
Of Hartmut Knaack
Sent: Friday, 5 May 2017 9:19 a.m.
To: Xuebing Wang; OpenWrt Development List
Cc: John Crispin
Subject: Re: [OpenWrt-Devel] Is "using gpio to simulate I2C bus" robust on 
AR9331?

Xuebing Wang schrieb am 04.05.2017 um 03:19:
> Hi community,
> 
> I am using Atheros AR9331 + OpenWRT Chaos Calmer 15.05 on a commercial 
> product.
> 
> I've used I2C on many projects, all with dedicated I2C controllers. 
> I've never used GPIOs to simulate I2C on Linux.
> 
> I may be wrong, I am tending to think that there is no way to generate 
> good I2C waveforms by using 2 GPIOs (SCL/SDA), except that we disable 
> all interrupts and maybe using high precision timer when outputing SCL/SDA?
> 
> Is "using gpio to simulate I2C bus" robust on AR9331?
> 

I have been using a GPIO extender connected via I2C to a router powered by an 
AR9132 (should be close enough), running for months without notable issues.
In that case, I2C traffic was pretty low, it just had to access the GPIOs of 
the extender a couple of times per hour. It has been way better than using an 
I2C-Tiny USB adapter, but that would be a different story.

> Thanks.
> Xuebing Wang
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [LEDE-DEV] Ubnt power beam board - back to defaults after reboot

2016-10-20 Thread Gareth Parker
Hi Jiri
This is a common problem on XM devices due to new uboot on AirOS >= 5.6.x,
although I haven't got any XW devices to test but its possibly the same?
Try downgrading back to AirOS v5.5.11 or less or apply the following patches
which I can confirm fix the problem on my XM devices.

https://raw.githubusercontent.com/freifunk-gluon/gluon/1f400189cfbae697b5018
0bccf876784a3c03423/patches/openwrt/0026-kernel-backport-spi-nor-driver-from
-4.4.9.patch
https://raw.githubusercontent.com/freifunk-gluon/gluon/1f400189cfbae697b5018
0bccf876784a3c03423/patches/openwrt/0027-kernel-mtd-spi-nor-wait-until-statu
s-register-writes-are-ready.patch
https://raw.githubusercontent.com/freifunk-gluon/gluon/1f400189cfbae697b5018
0bccf876784a3c03423/patches/openwrt/0028-kernel-mtd-spi-nor-unlock-Winbond-f
lashs.patch

Cheers,

Gareth

-Original Message-
From: Lede-dev [mailto:lede-dev-boun...@lists.infradead.org] On Behalf Of
Jiri Pirko
Sent: Thursday, 20 October 2016 8:29 p.m.
To: openwrt-devel@lists.openwrt.org; lede-...@lists.infradead.org
Subject: [LEDE-DEV] Ubnt power beam board - back to defaults after reboot

Hi.

Trying Ubiquity power beam M5. According to the instructions on openwrt
wiki, I'm using loco m5 firmware. All looks fine, only configuration is lost
after every reboot.

Tried:
openwrt-15.05.1-ar71xx-generic-ubnt-loco-m-xw-squashfs-sysupgrade.bin
openwrt-15.05-ar71xx-generic-ubnt-loco-m-xw-squashfs-sysupgrade.bin
openwrt-ar71xx-generic-ubnt-loco-m-xw-squashfs-sysupgrade.bin
lede-ar71xx-generic-ubnt-loco-m-xw-squashfs-sysupgrade.bin

All with the same result.

I remember I had some similar problem in past on a different board, and I
believe that there was and issue on definition of nand size. Not really
sure.

Any ideas?

Jiri

___
Lede-dev mailing list
lede-...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Tried to update ticket 20982 on dev.openwrt.org

2016-10-05 Thread Gareth Parker
All you need to do is access the web interface on 192.168.1.20 and flash 
through that, it will work as I've done it before.  Make sure you use the 
latest trunk or CC factory image.

Gareth

-Original Message-
From: acz...@gmail.com [mailto:acz...@gmail.com] On Behalf Of Aaron Z
Sent: Thursday, 6 October 2016 9:58 a.m.
To: Gareth Parker
Cc: OpenWrt Development List
Subject: Re: [OpenWrt-Devel] Tried to update ticket 20982 on dev.openwrt.org

On Wed, Oct 5, 2016 at 4:03 PM, Gareth Parker  wrote:
> The boot loader is different, XM v.5.5.11 was the last version to use the old 
> bootloader that worked when using tftp to flash openwrt, the new bootloader 
> starting with XM v5.6.x only accepts official ubnt firmware over tftp.  I can 
> confirm though you can still flash openwrt using the factory image in the web 
> interface.  The other option which I haven’t tested but it may possibly work 
> is to scp the sysupgrade image to /tmp/ on the ubnt device and then use mtd 
> to write directly.
Ah, I have been downgrading via the web interface to 5.5.10, then upgrading to 
OpenWrt from the web interface, but I don't have many to deal with.

Can you downgrade to XM v.5.5.11 via tftp and then flash OpenWrt from there?

Aaron Z
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Tried to update ticket 20982 on dev.openwrt.org

2016-10-05 Thread Gareth Parker
The boot loader is different, XM v.5.5.11 was the last version to use the old 
bootloader that worked when using tftp to flash openwrt, the new bootloader 
starting with XM v5.6.x only accepts official ubnt firmware over tftp.  I can 
confirm though you can still flash openwrt using the factory image in the web 
interface.  The other option which I haven’t tested but it may possibly work is 
to scp the sysupgrade image to /tmp/ on the ubnt device and then use mtd to 
write directly.

If ubnt would release the source for the newer u-boot then this tftp issue 
could be solved, but they don’t which is in clear violation of the GPL, my 
emails to them have fallen on deaf ears.

Gareth

-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf 
Of Aaron Z
Sent: Thursday, 6 October 2016 4:16 a.m.
To: Russell Senior
Cc: Bill Moffitt; OpenWrt Development List
Subject: Re: [OpenWrt-Devel] Tried to update ticket 20982 on dev.openwrt.org

Try downgrading the firmware to XM.v5.5.10 (I use 
http://www.ubnt.com/downloads/XN-fw-internal/v5.5.10/XM.v5.5.10.24241.141001.1649.bin
on my Nanostation LocoM2s at work)
It will complain about long passwords not being supported, but it will let you 
downgrade to it and then you can flash OpenWRT onto it.

Aaron Z
A human being should be able to change a diaper, plan an invasion, butcher a 
hog, conn a ship, design a building, write a sonnet, balance accounts, build a 
wall, set a bone, comfort the dying, take orders, give orders, cooperate, act 
alone, solve equations, analyze a new problem, pitch manure, program a 
computer, cook a tasty meal, fight efficiently, die gallantly. Specialization 
is for insects.
— Robert Heinlein, Time Enough for Love

On Wed, Oct 5, 2016 at 3:56 AM, Russell Senior  
wrote:
>> "Bill" == Bill Moffitt  writes:
>
> Bill> I have been busy with other things, but I finally got a shipment 
> Bill> of brand-new PicoStations (XM, identical to Bullet) here and 
> Bill> tried to flash both the trunk builds of OpenWRT and LEDE on them.
>
> Bill> I'm getting the same error I did some months back:
>
> Bill> sent DATA  received ERROR  Bill> msg=Firmware check failed> Error code 2: Firmware check failed 
> Bill> Sent 3407872 bytes in 6.6 seconds
>
> FWIW, I encountered the same behavior attempting to TFTP a recent LEDE 
> image to a Bullet M2HP.  The box says it was tested in March 2016.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [OpenWrt] #20982: jffs2-error / nanostation M5 xw / r47658

2016-06-17 Thread Gareth Parker
I can confirm this patch fixes the problem atleast on CC I haven’t tested any 
others.

https://raw.githubusercontent.com/freifunk-gluon/gluon/1f400189cfbae697b50180bccf876784a3c03423/patches/openwrt/0026-kernel-backport-spi-nor-driver-from-4.4.9.patch
https://raw.githubusercontent.com/freifunk-gluon/gluon/1f400189cfbae697b50180bccf876784a3c03423/patches/openwrt/0027-kernel-mtd-spi-nor-wait-until-status-register-writes-are-ready.patch
https://raw.githubusercontent.com/freifunk-gluon/gluon/1f400189cfbae697b50180bccf876784a3c03423/patches/openwrt/0028-kernel-mtd-spi-nor-unlock-Winbond-flashs.patch

All seem to apply cleanly to CC, compiled and tested on a Picostation running 
AirOS XM 5.6.2 with new uboot and no problems.

-Original Message-
From: OpenWrt [mailto:openwrt-devel@lists.openwrt.org] 
Sent: Wednesday, 15 June 2016 6:32 a.m.
Cc: openwrt-tick...@lists.openwrt.org
Subject: Re: [OpenWrt] #20982: jffs2-error / nanostation M5 xw / r47658

#20982: jffs2-error / nanostation M5 xw / r47658
+
  Reporter:  bittorf@…  |  Owner:  developers
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:
 Component:  packages   |Version:  Trunk
Resolution: |   Keywords:
+

Comment (by johnv):

 Here is a link to the commit, but this is not directly for CC.

 https://github.com/freifunk-gluon/gluon/issues/687#ref-commit-dd0535c

--
Ticket URL: 
OpenWrt 
Opensource Wireless Router Technology
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [OpenWrt] #20982: jffs2-error / nanostation M5 xw / r47658

2016-05-06 Thread Gareth Parker
I sent them one too and got a response back almost immediately:


Hi Gareth,

Thanks for getting in touch with us!

I'll check with my internal team and get back to you once I have any updates. 

Thanks!
Vann T
Ubiquiti Networks



That was a few hours ago, it will be interesting to see if they do give up the 
source code.  I could also try contacting our local authorized distributor here 
in NZ and see if they can help.


-Original Message-
From: OpenWrt [mailto:openwrt-devel@lists.openwrt.org] 
Sent: Friday, 6 May 2016 7:34 p.m.
Cc: openwrt-tick...@lists.openwrt.org
Subject: Re: [OpenWrt] #20982: jffs2-error / nanostation M5 xw / r47658

#20982: jffs2-error / nanostation M5 xw / r47658
+
  Reporter:  bittorf@…  |  Owner:  developers
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:
 Component:  packages   |Version:  Trunk
Resolution: |   Keywords:
+

Comment (by LeSpocky):

 Replying to [comment:33 gareth41@…]:
 > I tried loading trunk over 5.6.2 and could not save any settings.  It's  
 > something to do with this new u-boot version.  I think someone needs to  get 
 > hold of the source code of new u-boot from UBNT and analyze it,  shouldn't 
 > be too difficult given its GPL licensed and providing that UBNT  comply.

 I sent a mail to Ubiquiti support today requesting those sources, but  after 
reading http://libertybsd.net/ubiquiti/ and
 http://community.ubnt.com/t5/Business-Talk/Any-update-on-GPL-licence-
 violation/m-p/1428448#M47832 I'm not so sure if this will work out. :-/

--
Ticket URL: 
OpenWrt 
Opensource Wireless Router Technology
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH] Chaos Calmer - ath71xx: Add support for the Comfast CF-WR650AC

2016-05-04 Thread Gareth Parker
This patch adds support for the Comfast CF-WR650AC to Chaos Calmer.

More information is located at:
http://en.comfast.com.cn/product/SmartRepeater/item-217.html

I haven't been able to add this to Trunk as mac06_exchange_en is required
and was changed in r47956.  Without it the router hangs then reboots when
accessing anything switch related, either through swconfig or luci.

Signed-off-by: Gareth Parker 

diff --git
a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index e6fcec8..751b685 100644
---
a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++
b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -47,6 +47,10 @@ board=$(ar71xx_board_name)
 case "$FIRMWARE" in
 "ath10k/cal-pci-:00:00.0.bin")
case $board in
+   cf-wr650ac)
+   ath10kcal_extract "art" 20480 2116
+   ath10kcal_patch_mac $(macaddr_add $(cat
/sys/class/net/eth0/address) +3)
+   ;;
dlan-pro-1200-ac)
ath10kcal_extract "art" 20480 2116
;;
diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
index a4b355a..6fa4813 100644
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
@@ -50,6 +50,11 @@ bsb)
ucidef_set_led_default "sys" "SYS" "bsb:red:sys" "1"
;;
 
+cf-wr650ac)
+   ucidef_set_led_wlan "wlan2g" "WLAN 2.4 GHz" "comfast:blue:24g"
"phy1tpt"
+   ucidef_set_led_wlan "wlan5g" "WLAN 5 GHz" "comfast:blue:58g"
"phy0tpt"
+   ;;
+
 bullet-m | \
 nanostation-m | \
 rocket-m | \
diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
index b2e15bb..3ed8cf1 100755
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
@@ -64,6 +64,13 @@ tl-wdr4900-v2)
ucidef_add_switch_vlan "switch0" "2" "1 6"
;;
 
+cf-wr650ac)
+   ucidef_set_interfaces_lan_wan "eth0" "eth1"
+   ucidef_add_switch "switch0" "1" "1"
+   ucidef_add_switch_vlan "switch0" "1" "0 2 3 4 5"
+   ucidef_add_switch_vlan "switch0" "2" "1 6"
+   ;;
+
 bsb)
ucidef_set_interfaces_lan_wan "eth1" "eth0"
ucidef_add_switch "switch0" "1" "1"
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index dab4d2c..bdd76f9 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -396,6 +396,9 @@ ar71xx_board_detect() {
*CAP4200AG)
name="cap4200ag"
;;
+   *"CF-WR650AC")
+   name="cf-wr650ac"
+   ;;
*"CPE210/220/510/520")
name="cpe510"
tplink_pharos_board_detect
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index d025632..bbc06ab 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -400,6 +400,15 @@ platform_check_image() {
}
return 0
;;
+
+   cf-wr650ac)
+   [ "$magic_long" != "27051956" ] && {
+   echo "Invalid image type."
+   return 1
+   }
+   return 0
+   ;;
+
wndr3700 | \
wnr2000-v3 | \
wnr612-v2 | \
@@ -531,6 +540,7 @@ platform_do_upgrade() {
om5p-an)
platform_do_upgrade_openmesh "$ARGV"
;;
+   cf-wr650ac | \
unifi-outdoor-plus | \
uap-pro)
MTD_CONFIG_ARGS="-s 0x18"
diff --git a/target/linux/ar71xx/config-3.18
b/target/linux/ar71xx/config-3.18
index e2ff826..11cd969 100644
--- a/target/linux/ar71xx/config-3.18
+++ b/target/linux/ar71xx/config-3.18
@@ -48,6 +48,7 @@ CONFIG_ATH79_MACH_BSB=y
 CONFIG_ATH79_MACH_CAP4200AG=y
 CONFIG_ATH79_MACH_CARAMBOLA2=y
 CONFIG_ATH79_MACH_CPE510=y
+CONFIG_ATH79_MACH_CF_WR650AC=y
 CONFIG_ATH79_MACH_DB120=y
 CONFIG_ATH79_MACH_DGL_5500_A1=y
 CONFIG_ATH79_MACH_DHP_1565_A1=y
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-cf-wr650ac.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-cf-wr650ac.c

[OpenWrt-Devel] MAC swap handling for QCA8337N

2016-04-22 Thread Gareth Parker
First time posting to this list

I am adding support for the Comfast CF-WR650AC and have it working.  However
this router has a QCA8337N switch and MAC exchange needs to be enabled for
it to work properly or the router hangs and reboots when trying to access
anything switch related.

The problem is the QCA8337N in this device is not being enabled with MAC
exchange by default as it should be according to r47956.  There is no way to
manually enable either as was the case previously by using mac06_exchange_en
= true in the devices machine file.

I also have an EPG5000 with exactly the same switch type QCA8337N, this
device requires MAC exchange and previously had mac06_exchange_en = true in
its machine file, was removed in r47956 and I can confirm this device still
works no problem.

I changed the following so I could manually enable it and fix the problem.
It appears that the QCA8337N on at-least the CF-WR650AC is not automatically
enabled with MAC exchange for some reason.  If there is a better way I can
do this, please advise.

Gareth

diff --git a/target/linux/generic/files/drivers/net/phy/ar8327.c
b/target/linux/generic/files/drivers/net/phy/ar8327.c
index d879782..3a84e2c 100644
--- a/target/linux/generic/files/drivers/net/phy/ar8327.c
+++ b/target/linux/generic/files/drivers/net/phy/ar8327.c
@@ -505,7 +505,7 @@ ar8327_hw_config_pdata(struct ar8xxx_priv *priv,
data->port6_status = ar8327_get_port_init_status(&pdata->port6_cfg);

t = ar8327_get_pad_cfg(pdata->pad0_cfg);
-   if (chip_is_ar8337(priv) && !pdata->pad0_cfg->mac06_exchange_dis)
+   if ((chip_is_ar8337(priv) || pdata->pad0_cfg->mac06_exchange_en) &&
!pdata->pad0_cfg->mac06_exchange_dis)
t |= AR8337_PAD_MAC06_EXCHANGE_EN;
ar8xxx_write(priv, AR8327_REG_PAD0_MODE, t);

diff --git a/target/linux/generic/files/include/linux/ar8216_platform.h
b/target/linux/generic/files/include/linux/ar8216_platform.h
index 24bc442..a8d37ca 100644
--- a/target/linux/generic/files/include/linux/ar8216_platform.h
+++ b/target/linux/generic/files/include/linux/ar8216_platform.h
@@ -47,6 +47,7 @@ struct ar8327_pad_cfg {
bool sgmii_delay_en;
enum ar8327_clk_delay_sel txclk_delay_sel;
enum ar8327_clk_delay_sel rxclk_delay_sel;
+   bool mac06_exchange_en;
bool mac06_exchange_dis;
 };
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel