[OpenWrt-Devel] [PATCH] ath79: Add support for Ubiquity
lech.perczak at gmail.com
Sun Nov 18 11:03:46 EST 2018
Hi Petr, Joe,
W dniu 2018-11-18 o 10:03, Petr Štetiar pisze:
> Joe Ayers <joe at ayerscasa.com> [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 at AE6XE-NSM5XW-QTH:~# cat /etc/openwrt_version
> 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
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
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 at lists.openwrt.org
lech.perczak at gmail.com
Mobile: +48 694 309 185
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel