-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add firmware for Killer 1535 wireless module #42
Comments
Do we really need the /etc/modprobe.d/ath10.conf file? The standard Debian firmware package does not have this and I would prefer not to diverge too much from the upstream package. Also does it affect other non-"Killer" Atheros cards? |
Johnv, There has been an ongoing discussion between Dell, QCA and ourselves trying to nail this down. My most recent update shows that the latest ath10k driver in the current linux kernel combined with the latest firmware-4.bin and board-2.bin will work for ALL QCA6174/9377 based chips. Killer 1535 Boarddata has already included in the linux firmware repository: board-2.bin is a collection of multiple board data files with corresponding HWID information, and currently Killer 1535 BDF is already included. Regards, |
[ Upstream commit 79152e8 ] The tcrypt testing module on Exynos5422-based Odroid XU3/4 board failed on testing 8 kB size blocks: $ sudo modprobe tcrypt sec=1 mode=500 testing speed of async ecb(aes) (ecb-aes-s5p) encryption test 0 (128 bit key, 16 byte blocks): 21971 operations in 1 seconds (351536 bytes) test 1 (128 bit key, 64 byte blocks): 21731 operations in 1 seconds (1390784 bytes) test 2 (128 bit key, 256 byte blocks): 21932 operations in 1 seconds (5614592 bytes) test 3 (128 bit key, 1024 byte blocks): 21685 operations in 1 seconds (22205440 bytes) test 4 (128 bit key, 8192 byte blocks): This was caused by a race issue of missed BRDMA_DONE ("Block cipher Receiving DMA") interrupt. Device starts processing the data in DMA mode immediately after setting length of DMA block: receiving (FCBRDMAL) or transmitting (FCBTDMAL). The driver sets these lengths from interrupt handler through s5p_set_dma_indata() function (or xxx_setdata()). However the interrupt handler was first dealing with receive buffer (dma-unmap old, dma-map new, set receive block length which starts the operation), then with transmit buffer and finally was clearing pending interrupts (FCINTPEND). Because of the time window between setting receive buffer length and clearing pending interrupts, the operation on receive buffer could end already and driver would miss new interrupt. User manual for Exynos5422 confirms in example code that setting DMA block lengths should be the last operation. The tcrypt hang could be also observed in following blocked-task dmesg: INFO: task modprobe:258 blocked for more than 120 seconds. Not tainted 4.6.0-rc4-next-20160419-00005-g9eac8b7b7753-dirty #42 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. modprobe D c06b09d8 0 258 256 0x00000000 [<c06b09d8>] (__schedule) from [<c06b0f24>] (schedule+0x40/0xac) [<c06b0f24>] (schedule) from [<c06b49f8>] (schedule_timeout+0x124/0x178) [<c06b49f8>] (schedule_timeout) from [<c06b17fc>] (wait_for_common+0xb8/0x144) [<c06b17fc>] (wait_for_common) from [<bf0013b8>] (test_acipher_speed+0x49c/0x740 [tcrypt]) [<bf0013b8>] (test_acipher_speed [tcrypt]) from [<bf003e8c>] (do_test+0x2240/0x30ec [tcrypt]) [<bf003e8c>] (do_test [tcrypt]) from [<bf008048>] (tcrypt_mod_init+0x48/0xa4 [tcrypt]) [<bf008048>] (tcrypt_mod_init [tcrypt]) from [<c010177c>] (do_one_initcall+0x3c/0x16c) [<c010177c>] (do_one_initcall) from [<c0191ff0>] (do_init_module+0x5c/0x1ac) [<c0191ff0>] (do_init_module) from [<c0185610>] (load_module+0x1a30/0x1d08) [<c0185610>] (load_module) from [<c0185ab0>] (SyS_finit_module+0x8c/0x98) [<c0185ab0>] (SyS_finit_module) from [<c01078c0>] (ret_fast_syscall+0x0/0x3c) Fixes: a49e490 ("crypto: s5p-sss - add S5PV210 advanced crypto engine support") Cc: <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Tested-by: Marek Szyprowski <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
In addition, the latest ath10k driver is needed (via backports). This will enable not only the Killer 1535, but all QCA6174 hw3.0 based modules. |
Johnv, I just tested with the latest Brewmaster_Beta (2.88), and the ath10.conf file is still necessary. The wireless module does not load until this file is created with: As you noted the debian firmware package does not contain this. The latest kernel drivers/firmware packages no longer require this either, but that would require the ath10k driver/firmware packages be updated in the SteamOS kernel. Regards, |
If you can put together a pull request with the updated ath10k driver then we can easily accept it. Otherwise it will have to wait until one of us has time to do the work. |
Ath10k driver is present in the current steamOS kernel, but the necessary firmware files are missing. We have verified these steps work to have a Killer 1535 Wireless module work with a clean install of Brewmaster 2.70
Download:
http://www.killernetworking.com/support/K1535_Debian/board.bin
and put it in the /lib/firmware/ath10k/QCA6174/hw3.0/ folder (create the folder if it doesn’t exist)
Download:
http://www.killernetworking.com/support/K1535_Debian/firmware-4.bin
and put it in the /lib/firmware/ath10k/QCA6174/hw3.0/ folder as firmware-4.bin.
Create config file with:
sudo nano /etc/modprobe.d/ath10k.conf
and put the following contents into the file: options ath10k_core skip_otp=y
Reboot.
If a different method is preferred/verified, we would be fine with that as well.
Thanks,
Thomas
Rivet Networks
The text was updated successfully, but these errors were encountered: