@hnyman Look at this please. That will give an idea how to enable Wi-Fi on your device. You will need to load firmware too.
will try that in the next few days.
comparing to my own failing version, the difference is reg values plus mtd-cal-data value that I tried. And I did not load firmware separately 
This failed:
+&pcie0 {
+ status = "okay";
+
+ ath9k: wifi@0 {
+ compatible = "pci168c,ff1d";
+ reg = <0x0 0 0 0 0>;
+ qca,no-eeprom;
+ mtd-mac-address = <&art 0x0>;
+ mtd-cal-data = <&art 0x1000>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+};
And I am also confused with PCI device ID. In the log it shows ff1d for me too, but in
/sys/devices/pci0000:00/0000:00:11.0/device
it is 0029, that looks more correct.
You need to remove mtd-cal-data completely and load firmware by a script.
You can find reg value in your pci bus.
Can anybody help with creation of mk file for DIR-825B1.
I am very confused with all this legacy thing.
Look at the initvals used in F5D8235_V1.dts (ramips). I used it for a WNDR3800. Only the port 1 on the switch worked correctly without this..
Nice catch about the discrepancy. I had changed that in my DTS to ff1d due to the log lines, but also in my running ar71xx system there is the same discrepancy between log and /sys/devices, so possibly that 0029 is right (and matches PCI databases). I had tried that 0029 some time earlier, but had reverted to ff1d.
So I built a DIR825B1 image and flashed it. It boots and Ethernet part works.
But the problem is with PCIE.
[ 2.821006] PCI host bridge to bus 0000:00
[ 2.825154] pci_bus 0000:00: root bus resource [mem 0x10000000-0x16ffffff]
[ 2.832017] pci_bus 0000:00: root bus resource [io 0x0000]
[ 2.837584] pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0]
[ 2.844357] pci_bus 0000:00: No busn resource found for root bus, will use []
[ 2.852324] pci 0000:00:11.0: fixup device configuration
[ 2.859098] pci 0000:00:12.0: fixup device configuration
[ 2.865890] pci 0000:00:11.0: BAR 0: assigned [mem 0x10000000-0x1000ffff]
[ 2.872667] pci 0000:00:12.0: BAR 0: assigned [mem 0x10010000-0x1001ffff]
[ 2.879479] pci 0000:00:11.0: using irq 40 for pin 1
[ 2.884427] pci 0000:00:12.0: using irq 41 for pin 1
What is missing?
The dts pcie part is:
&pcie0 {
status = "okay";
ath9k0: wifi@168c,0029 {
compatible = "pci168c,0029";
reg = <0x0000 0 0 1 1>;
mtd-mac-address = <&caldata 0xffa0>;
qca,no-eeprom;
#gpio-cells = <2>;
gpio-controller;
};
ath9k1: wifi@168c,0029 {
compatible = "pci168c,0029";
reg = <0x0000 0 0 1 2>;
mtd-mac-address = <&caldata 0xffb4>;
mtd-mac-address-increment = <1>;
qca,no-eeprom;
#gpio-cells = <2>;
gpio-controller;
};
};
IRQ 40 and 41
That is more advanced that got into last month.
Did you adjust any kernel config options?
did you use CONFIG_ATH79_PCI_ATH9K_FIXUP=y ???
Now I need to rewrite the loading script, because it doesn't assume two PCI devices.
Job is almost done.
And we don't need to add ath9k leds manually. They work automatically and they are controlled.
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.