Skip to content
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

Open
twooden opened this issue Jul 8, 2016 · 5 comments
Open

Add firmware for Killer 1535 wireless module #42

twooden opened this issue Jul 8, 2016 · 5 comments

Comments

@twooden
Copy link

twooden commented Jul 8, 2016

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

@johnv-valve
Copy link
Contributor

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?

@twooden
Copy link
Author

twooden commented Aug 12, 2016

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:
http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/log/ath10k/QCA6174/hw3.0/board-2.bin

board-2.bin is a collection of multiple board data files with corresponding HWID information, and currently Killer 1535 BDF is already included.

Regards,
Thomas W
Rivet Networks

Plagman pushed a commit that referenced this issue Aug 15, 2016
[ 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]>
@twooden
Copy link
Author

twooden commented Aug 17, 2016

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.

@twooden
Copy link
Author

twooden commented Aug 23, 2016

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:
options ath10k_core skip_otp=y

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,
Thomas W
Rivet Networks

@johnv-valve
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants