Tagged: ath10k realtek ath9k
latest openwrt for cortexa53 target under mvebu does not see the wireless card at all. Neither does snapshot.
It is possible that Espressobin doesn’t provide previously mentioned/latest U-boot/ATF binaries which could have an effect on PCI functionality. Building them is a bit complicated while we manage to script the whole process not long ago.
yeah, this is quite the understatement ! I’ve been trying for months on end to build a viable u-boot+ATF and either never suceeded — broke my spi flash at least 20 times, or they detected only 512 mb of ram out of 2 gb. The wiki’s instructions are horribly out of date, so I’ve pretty much gave up on building it…
Note that I’m blind, as in totally blind, so messing around with jumpers to recover the bloody spi flash every time I fail a build is a pain, not to mention that I need an entire sata drive dedicated to aid in such a recovery.
That’s even worse than I anticipated, but anyway dmesg for snapshot would be helpful with output of
cat /proc/bus/pci/devices. Maybe there’s kernel module or even firmware missing for Your wireless card (since it also supports bluetooth)? For the record snapshot has backported wireless drivers from kernel 4.19rc4, so pretty much the newest out there.
and here is cat /proc/bus/pci/devices:
iw list does not show the card either, even with ath9k loaded.
Also, those are the only modules that I need according to the linux-wireless wiki: ath, ath9k, ath9k_hw, ath9k_common, and all of them are present in lsmod. More importantly, on my arch-arm and custom kernel the ath9k stuff is the only thing loaded, the card is recognized even though it crashes.
sorry, I missed the part about firmware missing for my card. The AR9565 aka QCB335 is one of these totally open source things. You only need the kernel driver — there is no firmware for it in linux-firmware, either. The thing has no binary blob and a FOSS driver hence why I thought it would be a good shot.
Have you tried Arch Linux?
I just can remember that my QCWB335 worked well under Arch, no patches or anything special required, just u-boot updated. If you want me to try something or provide you some more details, I will find my espressobin and check it out again (we are currently exploring the PC Engines apu2 platform, so I am not really using the espressobin anymore).
You keep talking about QCW335, not QCWB335. Does the B stand for bluetooth and you have the version without bluetooth?
I do have the version with bluetooth. This is the only version I was able to get my hands on in canada, all the others were unknown models to me. And I keep mispelling it, QCWB335.
And yes, as stated in earlier posts, the system I am running thing on is a buildroot custom made one, but I also tried openWRT which didn’t react to my card at all, and archlinux-arm, where my crash is reproducible every boot. I also posted on the linux-wireless mailing list in hope of getting some help somewhere.
Without updating u-boot is waste of time trying this and that distro. Tested on Armbian 4.18.y and updated u-boot of course: QCA9882, 9890, 9994 (ath10) and AR9380, 9382 … IIRC out of the box. Worse case you need to install designated firmware for ath10 based.
For USB, which you need for BT, to work on PCI slot you need to move a jumper.
I’ve checked the place where you seem to store u-boot images for the ebin, but can’t know which one is the right, for the life of me. I only know my board is 2 gb version, and there’s a ton of 2 gb files to choose from… Unless this is the stuff shown in u-boot, ddr @ 800mhz ?
Also, can the board perform recovery via anything else than sata, tftp, usb, whatever ?
I do want to flash the bootloader but I’m extremely careful, I can’t yet get my hands on a ups, and power is impossible to predict here, The 20 seconds it took to flash 2017.03 aramada v17.10 were agony in my experience, as as mentioned earlier, I don’t have a data drive to do such recovery from. Usb I do, sticks and drives, but definitely not sata.
The problem is that by default ath9k in OpenWrt is compiled without
ATH9K_SUPPORT_PCOEM enabled. I prepared images for You which have ath9k embedded:
Please test one of them and post Your dmesg.
Yeah… well most of the trace look similar (OpenWrt has more debug options enabled so the output is more “vocal”). Did people at #linux-wireless had any idea what might be causing it?
Well, we do know what is happening, in short. The whole driver ends up doing a sigbus while attempting to read from a particular memory address (always x19 in the stack trace that is the problem). We made sure the memory was actually mapped correctly, and it is. So in short, we know that whatever it attempts to read there, it goes bad, but we have no damn clue why.
As for the crash, the openWRT one is definitely more violent. The whole system does not end up doing a panic, neither on arch-arm nor on my buildroot made OS.
You must be logged in to reply to this topic.
Technical specification tables can not be displayed on mobile. Please view on desktop