So same as with tplink 1043ndv1 sometimes it works, sometimes it doesn't.
Everytime different. Even mac addresses appear different after a reboot ot two.
I give up for a while.
as far as i can see kernel image sizes are not much significantly larger than several years ago:
https://downloads.commotionwireless.net/nightly/ar71xx/
http://firmware.dptechnics.com/dptv1/1/
http://skelter.nikhef.nl/openwrt-bin/ar71xx/
all in .9-1.3mb range
my current build:
if the idea was to build kernel images containing only selected device profiles that could have been done by modifying buildscripts that generate kernel image. DTS loosers
You are mistaken (ar71xx/vmlinux.lzma):
- 8.09: 768.0 KB
- 10.03: 896.0 KB
- 12.09: 960.0 KB
- 14.07: 1088.0 KB
- 15.05: 1088.0 KB
- 17.01.0: 1280.0 KB
- 18.06.0: 1344.0 KB
- and kernel 4.14 is even larger, with 1472 KB (ar71xx/vmlinux.lzma) at the moment.
See https://openwrt.org/supported_devices/432_warning for a more detailed listing for the full image sizes.
Keep in mind, under ideal circumstances a device with 4 MB flash needs 128 KB for the bootloader and another 64 KB for ART, leaving you with 3900 KB for kernel, rootfs and overlay. However by far not all devices are ideal in this regard and waste space beyond this 'ideal' partitioning - furthermore many (most) devices also hardcode the sizes for kernel and rootfs.
you are still wrong! check my kernel images size, this was checked from git few weeks ago (4.9.111) and i haven't even optimized image for size or anything yet. for non-ideal devices you have u-boot_mod. or even better remove luci from official builds.
I think the problem with Wi-Fi on DIR-825b1 and wndr3800 is because the firmware doesn't load.
The FF1D device id is before the firmware has been loaded, and it gets changed to 0029 or something else when it's loaded. But the hotplug event is not triggered, that means that the driver doesn't attemt to load firmare. And ath9k doesn't have alias to this device.
So I figured all out with DIR825b1 and wndr3800 Wi-Fi.
The problem is that ar922x PCI device is detected as 0xff1d and it has no binding with ath9k.
When mach files were used, pci-ath9k-fixup was called and firmware was loaded from caldata that changed the device id to 0x0029.
Now this code seems to be dropped. The files pci-9ath9k-fixup.c and pci-9ath9k-fixup.h are still there, but they are not used any more.
To solve it a normal way a driver needs to be made bound to 168c:ff1d that will load the firmware. Then ath9k will catch the device. The same technology is used for ath3k bluetooth.
ath3k.ko loads fimware, then the device is managed by btusb.ko.
I am not sure that this is worth the effort.
2 Likes
Hm, I almost started writing this driver, but it appeared that it exists already.
It's called kmod-owl-loader. Install it and the device will be initiated.
But the problem is now that ath9k fails to load the firmware complaining to the magic number.
The wierd part is that owl-loader loads the firmware from the same file and checks the same magic number successfully, but then ath9k starts and fails to use the same file.
So now I got the correct ID, got IRQs, but stopped at loading firmware.
Hotplug is never called.
So the DIR-825b1 is almost done.
All is working, but I am struggling with scripts that set mac addresses.
And we need to fix wireless leds.
@hnyman I can do the PR for WNDR3800, but can you help me too?
Im very bad in bash. I need scripts for getting mac addresses.
I can do the PR for WNDR3800, no problem with that.
But I need to compile the test build first 
And if your PR gets accepted and merged first, I can simply modify your 10-ath9k-eeprom by adding lines for WNDR3800 there (instead of adding the whole sections in the PR).
@hnyman Can you help with the mac address scripts. They don't work.
My device can't get them in dts.
How is it coded in caldata? Not the normal 6-bytes MAC?
Ps. You have a typo on the commit: "suuport"
@most
In the Github PR you suggested removing the reset for 8 / phy for eth0 in WNDR3800 (and leaving only 9 / mac). Where did that come from? Likely quite correct, but why?
I got the wifi working on WNDR3800, thanks for pointers. Did not much test it, but works at least somehow.
I still wonder about
- the shared IRQ 12 for wlan0 and wlan1
- the MAC addresses (how should wlan0 have different MAC than eth0, if the "locally managed address" bit can't be set in DTS. )
It is stored in ascii in the form of 00:11:22:33:44:55.
Actually I figured that out. It didn't accept the script after sysupgrade. firstboot was needed.
...suggested removing the reset for 8 / phy for eth0 in WNDR3800... Likely quite correct, but why?
To remove the resets was suggested by 981213 ~2 days ago in the PR:
Try to remove the phy resets defined in ar7100.dtsi. they might cause some unwanted switch reset if the switch reset pin is connected to either ETH0_RESET_L or ETH1_RESET_L.
I guess that then is the case. Or should that instead be stated as a "switch" reset in the switch section (that I have seen in some dts files)?
I previously have tried to use initvals to mitigate the problems there was with the switch that only port 1 worked correctly. Initvals seemed to have solved the problem as well (I found some values for ramips based unit that also had rtl8366s).
I don't really understand how the eth0 and eth1 interfaces are connected with the switch and with the phy (for eth0 and eth1 respectively). One thing that I think is odd is that the switch is involved as well in the eth1 interface somehow? (the phy is connected trough the mdio-bus sorted under the switch entry in the dts.) I tested a lot of variants to solve the switch problem, including creating a separate mdio0 entry outside the switch. Not really successfull.
Why is only the mac reset kept for the eth1 interface in the current dts file? For me it makes sense to have the phy reset there.
the shared IRQ 12 for wlan0 and wlan1
I wonder as well. According to juppin above (June 10) there is a dummy irq driver in ar71xx - so maybe that is ok to appear to share IRQ? (according to juppin there are physical IRQs between 0-7).
the MAC addresses..."locally managed address" bit...
There is a hotplug script 10_fix_wifi_mac. Can that be adjusted?
Regarding wlan0 having the earlier the same MAC address (read from art) as eth0:
Set the locally administered bit on the eth0 MAC to make it unique. ...
In the ar71xx version, eth0 has the first byte of MAC has been ORred with 2 to make it unique (and "locally administered"). C6:3D:xx:xx:3F:50 for eth0 vs. C4:3D:xx:xx:3F:50 for wlan0
Could be.
Other alternative might be to extend the Openwrt-specific kernel patch that defines mtd-mac-address property: https://github.com/openwrt/openwrt/blob/master/target/linux/generic/pending-4.14/681-NET-add-of_get_mac_address_mtd.patch
It might be enhanced to mimic the same actions that init ath79_init_local_mac has done earlier. https://github.com/openwrt/openwrt/blob/c49ae68cbaf078a3dacaebf453d9e7ece2e861f5/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c#L1247
That could be done by defining an additional property in style of mtd-mac-address-increment that would then toggle the one bit to set "locally managed" status.
But that might be farfetched, as there are apparently only 4 users of init ath79_init_local_mac function in ar71xx.
I got also the wifi LEDs to work in WNDR3800 with the patch below. I used the same LED names as are visible in ar71xx.
diff --git a/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom b/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
index b55ae0dbb3..36d1b249f0 100644
--- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
+++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
@@ -71,4 +71,24 @@ case "$FIRMWARE" in
;;
esac
;;
+"ath9k-eeprom-pci-0000:00:11.0.bin")
+ case $board in
+ netgear,wndr3800)
+ ath9k_eeprom_extract "art" 4096 3768
+ ;;
+ *)
+ ath9k_eeprom_die "board $board is not supported yet"
+ ;;
+ esac
+ ;;
+"ath9k-eeprom-pci-0000:00:12.0.bin")
+ case $board in
+ netgear,wndr3800)
+ ath9k_eeprom_extract "art" 20480 3768
+ ;;
+ *)
+ ath9k_eeprom_die "board $board is not supported yet"
+ ;;
+ esac
+ ;;
esac
diff --git a/target/linux/ath79/dts/ar7161_netgear_wndr3800.dts b/target/linux/ath79/dts/ar7161_netgear_wndr3800.dts
index 59b868480a..4ccd7533e0 100644
--- a/target/linux/ath79/dts/ar7161_netgear_wndr3800.dts
+++ b/target/linux/ath79/dts/ar7161_netgear_wndr3800.dts
@@ -70,6 +70,22 @@
};
};
+ ath9k-leds {
+ compatible = "gpio-leds";
+ wlan2g {
+ label = "ath9k-phy0";
+ gpios = <&ath9k0 5 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ linux,default-trigger = "phy0tpt";
+ };
+ wlan5g {
+ label = "ath9k-phy1";
+ gpios = <&ath9k1 5 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ linux,default-trigger = "phy1tpt";
+ };
+ };
+
gpio-keys-polled {
compatible = "gpio-keys-polled";
#address-cells = <1>;
@@ -137,6 +153,24 @@
&pcie0 {
status = "okay";
+
+ ath9k0: wifi@0,11 {
+ compatible = "pci168c,0029";
+ reg = <0x8800 0 0 0 0x10000>;
+ mtd-mac-address = <&art 0x0>;
+ qca,no-eeprom;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+
+ ath9k1: wifi@0,12 {
+ compatible = "pci168c,0029";
+ reg = <0x9000 0 0 0 0x10000>;
+ mtd-mac-address = <&art 0xc>;
+ qca,no-eeprom;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
};
&uart {
@@ -192,6 +226,9 @@
mtd-mac-address = <&art 0x00>;
+ resets = <&rst 9>;
+ reset-names = "mac";
+
fixed-link {
speed = <1000>;
full-duplex;
diff --git a/target/linux/ath79/image/generic.mk b/target/linux/ath79/image/generic.mk
index a6de86eade..e5c4bd0fb2 100644
--- a/target/linux/ath79/image/generic.mk
+++ b/target/linux/ath79/image/generic.mk
@@ -115,7 +115,7 @@ define Device/netgear_wndr3800
IMAGE/default := append-kernel | pad-to $$$$(BLOCKSIZE) | netgear-squashfs | append-rootfs | pad-rootfs
IMAGE/sysupgrade.bin := $$(IMAGE/default) | append-metadata | check-size $$$$(IMAGE_SIZE)
IMAGE/factory.img := $$(IMAGE/default) | netgear-dni | check-size $$$$(IMAGE_SIZE)
- DEVICE_PACKAGES := kmod-usb-core kmod-usb-ohci kmod-usb2 kmod-usb-ledtrig-usbport kmod-leds-reset
+ DEVICE_PACKAGES := kmod-usb-core kmod-usb-ohci kmod-usb2 kmod-usb-ledtrig-usbport kmod-leds-reset kmod-owl-loader
SUPPORTED_DEVICES += wndr3800
endef
TARGET_DEVICES += netgear_wndr3800
I included above your reset change, although it is a separate issue, I think.
Note that the patch above still has the same unadjusted MAC for eth0 and wlan0
@hnyman Does forwarding from lan to wan work for you?
It doesn't for me. This happened before on other devices and is probably unrelated.
The break firewall in trunk from time to time.
So I finished DIR-825, I can create a PR for 3800.