| 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 | expand |
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
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
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
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
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>; + }; +}; + +ð0 { + 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
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