Hi Petr, Joe,
W dniu 2018-11-18 o 10:03, Petr Štetiar pisze:
Joe Ayers <j...@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@AE6XE-NSM5XW-QTH:~# cat /etc/openwrt_version
r7258-5eb055306f
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
somewhere.
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
"target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom" -
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@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
--
Pozdrawiam,
Lech Perczak
lech.perc...@gmail.com
Mobile: +48 694 309 185
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
