[OpenWrt-Devel] [PATCH] ath79: add support for ZyXEL NWA1123-NI

Adrian Schmutzler mail at adrianschmutzler.de
Mon Oct 28 11:23:15 EDT 2019


> -----Original Message-----
> From: openwrt-devel [mailto:openwrt-devel-bounces at lists.openwrt.org] On Behalf Of 'Patrick Supper'
> Sent: Freitag, 25. Oktober 2019 21:50
> To: openwrt-devel at 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?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20191028/38fe151a/attachment.sig>
-------------- next part --------------
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list