[OpenWrt-Devel] ath79: add support for ZyXEL NWA1123-NI
diff mbox series

Message ID 20191024115430.19992-1-openwrt.dev@krtzbrtz.org
State New
Delegated to: David Bauer
Headers show
Series
  • [OpenWrt-Devel] ath79: add support for ZyXEL NWA1123-NI
Related show

Commit Message

'Patrick Supper' Oct. 24, 2019, 11:54 a.m. UTC
ZyXEL NWA1123-NI is a dual band 802.11n access point.

The factory firmware partition table is using a small kernel partition
after the rootfs partition. Since it has to be flashed using UART I also
merged 3 partitions (rootfs, uImage, reserve) to one firmware partition
and changed the default load address in U-Boot.

* Specification:
- SoC: Atheros AR9342 @560MHz
- RAM: 64 MiB
- Flash: 16 MiB NOR
- Ethernet: 10/100/1000 Mbps (Atheros AR8035 PHY)
- WiFi 2.4GHz: Atheros AR9340 (SoC) 802.11bgn 2×2:2
- WiFi 5.0GHz: Atheros AR9382 (PCIe) 802.11an 2×2:2
- Button: 1 (reset)
- LED: 1 (amber/green)
- Power: DC 12V/1A Barrel, PoE 802.3af
- Bootloader: U-Boot 1.1.4 (Qualcomm/Atheros SDK)

Serial Port header is located next to the On-PCB-Antenna "ANT2"
Pin 1: VCC +3.3V (small circle silkscreened)
    2: TX
    3: RX
    4: GND

* Install / Flash instruction:
Use the squashfs-sysupgrade.bin image. Set up a TFTP server, connect to
serial port and press any key after powering up the device to enter
U-boot shell.

1. Change the default boot command and unset bootargs:
     setenv bootcmd 'bootm 0x9f050000'
     setenv bootargs
     saveenv
2. Set your router ipaddr and server ipaddr. e.g.:
     setenv ipaddr 192.168.1.11
     setenv serverip 192.168.1.120
3. Load and flash the firmware:
     tftp 0x80060000 fw.bin
     erase 0x9f050000 +$filesize
     cp.b $fileaddr 0x9f050000 $filesize
4. Reset your device:
     reset
5. Wait for the LED to turn from blinking amber to solid green (ca 2min)

* Known Issue:
- U-Boot does NOT support booting large initramfs images from RAM,
  they need to be written to flash first.

Signed-off-by: Patrick Supper <openwrt.dev@krtzbrtz.org>
---
 .../ath79/base-files/etc/board.d/02_network   |   3 +-
 .../ath79/dts/ar9342_zyxel_nwa1123-ni.dts     | 161 ++++++++++++++++++
 target/linux/ath79/image/generic.mk           |   8 +
 3 files changed, 171 insertions(+), 1 deletion(-)
 create mode 100644 target/linux/ath79/dts/ar9342_zyxel_nwa1123-ni.dts

Comments

Adrian Schmutzler Oct. 25, 2019, 11:26 a.m. UTC | #1
Hi,

> +			partition@50000 {
> +				compatible = "denx,uimage";
> +				label = "firmware";
> +				reg = <0x050000 0xF50000>;

I'd prefer lower-case for the address (and for consistency with your other definitions).

> +			art: partition@ff0000 {
> +				label = "ART";

Please use lower case here. This is used consistently across ath79 target.

> +				reg = <0xff0000 0x010000>;
> +				read-only;
> +			};
> +		};
> +	};
> +};
> +
> +
> +&pcie {
> +	status = "okay";
> +
> +	wifi@0,0 {
> +		compatible = "168c,0030";
> +		reg = <0x0000 0 0 0 0>;
> +		mtd-mac-address = <&art 0x1002>;
> +		mtd-mac-address-increment = <2>;
> +		qca,disable-2ghz;

No caldata extraction? Or am I missing something?

> +	};
> +};
> +
> +&wmac {
> +	status = "okay";
> +	qca,disable-5ghz;
> +	mtd-cal-data = <&art 0x1000>;
> +	mtd-mac-address = <&art 0x1002>;
> +	mtd-mac-address-increment = <1>;

Normally, 0x1002 is the address read automatically when mtd-cal-data is 0x1000. It is very unlikely that vendor initializes an address to the correct location and then overwrites it with an increment.

Please provide the MAC address assignment with vendor firmware.
Based on that information, check whether you find those addresses in art (with hexdump, or by reading typical locations). For reference, check out https://openwrt.org/docs/guide-developer/mac.address

After that, please share the results with us.

Best

Adrian
'Patrick Supper' Oct. 25, 2019, 7:50 p.m. UTC | #2
Hello,

thank you for reviewing. I just changed the address and ART-Label to 
lowercase in my source => fixed.

### Regarding the cal-data of the pcie-wifi (AR9382):
It seems to me it has some kind of EEPROM, from OEM-BootLog:
wmac-wifi: "Using Cal data from Flash 0xbfff0000"
pcie-wifi: "Using Cal data from EEPROM 0x3ff"

At least I was able to identify only one cal-data section in art, 
starting at 0x1000. Starting from 0x1450 art is totally empty.

On OpenWrt ath9k does not complain about missing cal-data and the 
wifi-interface is functional.

Please let me know if I might be right with my assumption, and if so, 
shall i write a comment in the dts?
For example: /* has cal-data in eeprom */

Logfiles from OpenWrt and OEM are available on the Device-Wiki:
https://openwrt.org/inbox/zyxel/zyxel_nwa1123-ni

### MAC addresses

# OEM-Firmware takes them from mib0 (/etc/rc.d/rcS and 
/etc/rc.d/rc.wlan), in short:

	strings /dev/mtdblock6 > /tmp/mtdblock6
	TEMP=`cat /tmp/mtdblock6 | grep 'eth0mac' | awk '{print $3}'`
	ETH0MAC=`expr substr $TEMP 9 17`
	ifconfig eth0 hw ether $ETH0MAC

	TEMP=`cat /tmp/mtdblock6 | grep 'wifi0mac' | awk '{print $4}'`
	WIFI0MAC=`expr substr $TEMP 10 17`
	iwpriv wifi0 setHwaddr $WIFI0MAC

	TEMP=`cat /tmp/mtdblock6 | grep 'wifi1mac' | awk '{print $5}'`
	WIFI1MAC=`expr substr $TEMP 10 17`
	iwpriv wifi1 setHwaddr $WIFI1MAC

# strings /dev/mtdblock6 (mib0) gives:
serialnum=S122L12345678 countrycode=276 eth0mac=00:11:22:33:44:05 
wifi0mac=00:11:22:33:44:06 wifi1mac=00:11:22:33:44:07
(yes, all in one line and not usable with mtd_get_mac_ascii by default)

# "strings /dev/mtd1 | grep mac" (u-boot-env) gives:
eth0mac=00:37:ff:00:00:01
wifi0mac=00:37:ff:00:00:02
wifi1mac=00:37:ff:00:00:03

...but those are generic and identical on all my devices => not usable 
by default

# art contains a valid MAC address at 0x1002, but it is the on of eth0

I guess that explains why i decided to use the following to set the 
mac-addresses:

eth0:  <&art 0x1002>
wifi0: <&art 0x1002> + 1
wifi1: <&art 0x1002> + 2

I have 4 of this devices and for those this is correct.
But i have to admit that i got them all at the same time and the vendor 
might have changed to set a valid/correct MAC address for eth0 at art 
0x1002 before/after i got mine...

How shall we proceed with this? Keep the current solution (with the risk 
that some users maybe end up with wrong MAC-addresses)? Or extend 
mtd_get_mac_ascii with an option for white-space as a field separator 
(or create a new function) and set the MAC address in 
/etc/board.d/02_network + /etc/hotplug.d/firmware/10-ath9k-eeprom?

Regards,
Patrick
Adrian Schmutzler Oct. 28, 2019, 3:23 p.m. UTC | #3
Hi,

> -----Original Message-----
> From: openwrt-devel [mailto:openwrt-devel-bounces@lists.openwrt.org] On Behalf Of 'Patrick Supper'
> Sent: Freitag, 25. Oktober 2019 21:50
> To: openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH] ath79: add support for ZyXEL NWA1123-NI
> 
> Hello,
> 
> thank you for reviewing. I just changed the address and ART-Label to
> lowercase in my source => fixed.
> 
> ### Regarding the cal-data of the pcie-wifi (AR9382):
> It seems to me it has some kind of EEPROM, from OEM-BootLog:
> wmac-wifi: "Using Cal data from Flash 0xbfff0000"

Note that you are currently using art 0x1000, so 0xff1000 inside flash?!

> pcie-wifi: "Using Cal data from EEPROM 0x3ff"
> 
> At least I was able to identify only one cal-data section in art,
> starting at 0x1000. Starting from 0x1450 art is totally empty.
> 
> On OpenWrt ath9k does not complain about missing cal-data and the
> wifi-interface is functional.
> 
> Please let me know if I might be right with my assumption, and if so,
> shall i write a comment in the dts?
> For example: /* has cal-data in eeprom */
> 
> Logfiles from OpenWrt and OEM are available on the Device-Wiki:
> https://openwrt.org/inbox/zyxel/zyxel_nwa1123-ni
> 
> ### MAC addresses
> 
> # OEM-Firmware takes them from mib0 (/etc/rc.d/rcS and
> /etc/rc.d/rc.wlan), in short:
> 
> 	strings /dev/mtdblock6 > /tmp/mtdblock6
> 	TEMP=`cat /tmp/mtdblock6 | grep 'eth0mac' | awk '{print $3}'`
> 	ETH0MAC=`expr substr $TEMP 9 17`
> 	ifconfig eth0 hw ether $ETH0MAC
> 
> 	TEMP=`cat /tmp/mtdblock6 | grep 'wifi0mac' | awk '{print $4}'`
> 	WIFI0MAC=`expr substr $TEMP 10 17`
> 	iwpriv wifi0 setHwaddr $WIFI0MAC
> 
> 	TEMP=`cat /tmp/mtdblock6 | grep 'wifi1mac' | awk '{print $5}'`
> 	WIFI1MAC=`expr substr $TEMP 10 17`
> 	iwpriv wifi1 setHwaddr $WIFI1MAC
> 
> # strings /dev/mtdblock6 (mib0) gives:
> serialnum=S122L12345678 countrycode=276 eth0mac=00:11:22:33:44:05
> wifi0mac=00:11:22:33:44:06 wifi1mac=00:11:22:33:44:07
> (yes, all in one line and not usable with mtd_get_mac_ascii by default)
> 
> # "strings /dev/mtd1 | grep mac" (u-boot-env) gives:
> eth0mac=00:37:ff:00:00:01
> wifi0mac=00:37:ff:00:00:02
> wifi1mac=00:37:ff:00:00:03
> 
> ...but those are generic and identical on all my devices => not usable
> by default
> 
> # art contains a valid MAC address at 0x1002, but it is the on of eth0
> 
> I guess that explains why i decided to use the following to set the
> mac-addresses:
> 
> eth0:  <&art 0x1002>
> wifi0: <&art 0x1002> + 1
> wifi1: <&art 0x1002> + 2
> 
> I have 4 of this devices and for those this is correct.
> But i have to admit that i got them all at the same time and the vendor
> might have changed to set a valid/correct MAC address for eth0 at art
> 0x1002 before/after i got mine...
> 
> How shall we proceed with this? Keep the current solution (with the risk
> that some users maybe end up with wrong MAC-addresses)? Or extend
> mtd_get_mac_ascii with an option for white-space as a field separator
> (or create a new function) and set the MAC address in
> /etc/board.d/02_network + /etc/hotplug.d/firmware/10-ath9k-eeprom?

Thanks for the extensive answer.

I'm not 100 % convinced about it, but to me using the strings seems to be the most proper solution in this context.

I'm a little surprised about your strings output. As I understand it, the separator is determined by the strings function, and not by the data read (I'm not an expert.)?

Maybe they use some special space characters in the data which can be converted by tr "X" "\n" or some other simple solution?

Best

Adrian
'Patrick Supper' Oct. 28, 2019, 8:17 p.m. UTC | #4
Hello,

>> ### Regarding the cal-data of the pcie-wifi (AR9382):
>> It seems to me it has some kind of EEPROM, from OEM-BootLog:
>> wmac-wifi: "Using Cal data from Flash 0xbfff0000"
> 
> Note that you are currently using art 0x1000, so 0xff1000 inside flash?!
> 

ART-Partition starts at 0xff0000 in flash. Cal-data starts at 0xff1000 
if i got it right.

OEM-Firmware uses OpenWrt but proprietary Atheros-Drivers, to be honest 
i don't know what they really do, but i guess they use a offset of 
0x1000 from start of art for cal-data?

# OEM-Firmware, art (MAC-Addr changed):
/ # hexdump /dev/mtd7
0000000 0030 ab11 20e1 ffff ffff ffff ffff ffff
0000010 ffff ffff ffff ffff ffff ffff ffff ffff
*
0001000 0202 0011 2233 4455 0030 3a62 323a 6463
0001010 ...


>> How shall we proceed with this? Keep the current solution (with the risk
>> that some users maybe end up with wrong MAC-addresses)? Or extend
>> mtd_get_mac_ascii with an option for white-space as a field separator
>> (or create a new function) and set the MAC address in
>> /etc/board.d/02_network + /etc/hotplug.d/firmware/10-ath9k-eeprom?
> 
> Thanks for the extensive answer.
> 
> I'm not 100 % convinced about it, but to me using the strings seems to be the most proper solution in this context.
> 
> I'm a little surprised about your strings output. As I understand it, the separator is determined by the strings function, and not by the data read (I'm not an expert.)?
> 
> Maybe they use some special space characters in the data which can be converted by tr "X" "\n" or some other simple solution?
> 


 From man-page ("normal" strings, not the BusyBox):
"strings prints the printable character sequences that are at least 4 
characters long (or the number given with the options below) and are 
followed by an unprintable character."

In the case of for example u-boot-env the separation between the various 
"key=value" is 0x00, which is "Null" and not a printable character.

In the case of the mib0-partition it uses normal white space (0x20) as 
separator (=printable), that's why mtd_get_mac_ascii does not give the 
expected result.

But it works with replacing the space with newline:
tr ' ' '\n'

What if we set the MAC-Addresses manually in the u-boot-env and take 
them from there? (uboot-env needs to be changed anyway for setting the 
new address for bootm; so at the moment it is just an other step for the 
Install/Flash-Instructions)

Regards,
Patrick

Patch
diff mbox series

diff --git a/target/linux/ath79/base-files/etc/board.d/02_network b/target/linux/ath79/base-files/etc/board.d/02_network
index c40c07a906..67701294b4 100755
--- a/target/linux/ath79/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/base-files/etc/board.d/02_network
@@ -54,7 +54,8 @@  ath79_setup_interfaces()
 	ubnt,unifiac-mesh|\
 	ubnt,unifi|\
 	wd,mynet-wifi-rangeextender|\
-	winchannel,wb2000)
+	winchannel,wb2000|\
+	zyxel,nwa1123-ni)
 		ucidef_set_interface_lan "eth0"
 		;;
 	avm,fritz4020|\
diff --git a/target/linux/ath79/dts/ar9342_zyxel_nwa1123-ni.dts b/target/linux/ath79/dts/ar9342_zyxel_nwa1123-ni.dts
new file mode 100644
index 0000000000..348a3d69cc
--- /dev/null
+++ b/target/linux/ath79/dts/ar9342_zyxel_nwa1123-ni.dts
@@ -0,0 +1,161 @@ 
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+#include "ar9344.dtsi"
+
+/ {
+	compatible = "zyxel,nwa1123-ni", "qca,ar9342";
+	model = "ZyXEL NWA1123-NI";
+
+	aliases {
+		led-boot = &status_amber;
+		led-failsafe = &status_amber;
+		led-running = &status_green;
+		led-upgrade = &status_amber;
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		status_amber: power_amber {
+			label = "zyxel:amber:power";
+			gpios = <&gpio 11 GPIO_ACTIVE_LOW>;
+		};
+
+		status_green: power_green {
+			label = "zyxel:green:power";
+			gpios = <&gpio 12 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	keys {
+		compatible = "gpio-keys";
+
+		reset {
+			label = "reset";
+			linux,code = <KEY_RESTART>;
+			gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
+			debounce-interval = <60>;
+		};
+	};
+};
+
+&ref {
+	clock-frequency = <40000000>;
+};
+
+&uart {
+	status = "okay";
+};
+
+&gpio {
+	status = "okay";
+};
+
+&spi {
+	status = "okay";
+	num-cs = <1>;
+
+	flash@0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		spi-max-frequency = <25000000>;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			partition@0 {
+				label = "u-boot";
+				reg = <0x000000 0x040000>;
+				read-only;
+			};
+
+			partition@40000 {
+				label = "u-boot-env";
+				reg = <0x040000 0x010000>;
+				read-only;
+			};
+
+			partition@50000 {
+				compatible = "denx,uimage";
+				label = "firmware";
+				reg = <0x050000 0xF50000>;
+			};
+
+			partition@fa0000 {
+				label = "config";
+				reg = <0xfa0000 0x040000>;
+				read-only;
+			};
+
+			partition@fe0000 {
+				label = "mib0";
+				reg = <0xfe0000 0x010000>;
+				read-only;
+			};
+
+			art: partition@ff0000 {
+				label = "ART";
+				reg = <0xff0000 0x010000>;
+				read-only;
+			};
+		};
+	};
+};
+
+
+&pcie {
+	status = "okay";
+
+	wifi@0,0 {
+		compatible = "168c,0030";
+		reg = <0x0000 0 0 0 0>;
+		mtd-mac-address = <&art 0x1002>;
+		mtd-mac-address-increment = <2>;
+		qca,disable-2ghz;
+	};
+};
+
+&wmac {
+	status = "okay";
+	qca,disable-5ghz;
+	mtd-cal-data = <&art 0x1000>;
+	mtd-mac-address = <&art 0x1002>;
+	mtd-mac-address-increment = <1>;
+};
+
+&mdio0 {
+	status = "okay";
+
+	phy-mask = <0>;
+
+	phy0: ethernet-phy@0 {
+		reg = <0>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+
+	/* default for ar934x, except for 1000M and 10M */
+	pll-data = <0x06000000 0x00000101 0x00001313>;
+
+	mtd-mac-address = <&art 0x1002>;
+
+	phy-mode = "rgmii-id";
+	phy-handle = <&phy0>;
+
+	gmac-config {
+		device = <&gmac>;
+		rxdv-delay = <3>;
+		rxd-delay = <3>;
+		txen-delay = <3>;
+		txd-delay = <3>;
+		rgmii-gmac0 = <1>;
+	};
+};
diff --git a/target/linux/ath79/image/generic.mk b/target/linux/ath79/image/generic.mk
index e82e125166..0f13fad7b2 100644
--- a/target/linux/ath79/image/generic.mk
+++ b/target/linux/ath79/image/generic.mk
@@ -1022,3 +1022,11 @@  define Device/zbtlink_zbt-wd323
 		     kmod-usb-serial kmod-usb-serial-cp210x uqmi
 endef
 TARGET_DEVICES += zbtlink_zbt-wd323
+
+define Device/zyxel_nwa1123-ni
+  ATH_SOC := ar9342
+  DEVICE_VENDOR := ZyXEL
+  DEVICE_MODEL := NWA1123-NI
+  IMAGE_SIZE := 15680k
+endef
+TARGET_DEVICES += zyxel_nwa1123-ni