-
Notifications
You must be signed in to change notification settings - Fork 124
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
consider changing paths for WCNSS_qcom_wlan_nv.bin #339
Comments
Yes, this is one of the not-yet-solved things we need to do... Unfortunately we can't reliably use msm-fw-loader since some (many) devices keep this config in /system, so we have to package them. For the select few that contain it in /persist, the fw-loader has code to handle it: https://gitlab.com/postmarketOS/msm-firmware-loader/-/blob/master/msm-firmware-loader.sh?ref_type=heads#L109-113 One of the ides we had is to collect all the nv files, name them per-board and create a big dump repo to install in the os, then add firmware-name to all the devices dts. Unfortunately we still had few open questions (like who would host this archive, what licensing considerations are there for distributing those files...) and so it was on a back burner for a while now... |
(cont. after I accidentally pressed ctrl+enter) FWIW the devices seem to work semi-fine even using the sbc's nv file. This is, theoretically, wrong due to the different antenna calibration, but doesn't, for example, prevent 5GHz devices from working properly... If you need a stop-gap for testing, you could probably use that fine. |
It is noted that even for the same model, different devices can ship different nv configs. I've downloaded many ufi-001c firmwares from the Internet and verified so. Also there are many variants that are almost identical. e.g. ufi-001b and ufi-001c. While they can share one device tree and linux kernel, they ship different modem firmwares and nv configs. Trying to reuse them has caused a lot of trouble in the OpenStick project. |
Add a test case which replaces an active ingress qdisc while keeping the miniq in-tact during the transition period to the new clsact qdisc. # ./vmtest.sh -- ./test_progs -t tc_link [...] ./test_progs -t tc_link [ 3.412871] bpf_testmod: loading out-of-tree module taints kernel. [ 3.413343] bpf_testmod: module verification failed: signature and/or required key missing - tainting kernel #332 tc_links_after:OK #333 tc_links_append:OK #334 tc_links_basic:OK #335 tc_links_before:OK #336 tc_links_chain_classic:OK #337 tc_links_chain_mixed:OK #338 tc_links_dev_chain0:OK #339 tc_links_dev_cleanup:OK #340 tc_links_dev_mixed:OK #341 tc_links_ingress:OK #342 tc_links_invalid:OK #343 tc_links_prepend:OK #344 tc_links_replace:OK #345 tc_links_revision:OK Summary: 14/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <[email protected]> Cc: Martin KaFai Lau <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin KaFai Lau <[email protected]>
I'm looking into implementing a generic port for these devices, and I'm facing this problem: we have this file in the same path on all devices, so we can't install all of them at the same time.
It can be fixed by changing firmware path and according to https://github.com/torvalds/linux/blob/be3ca57cfb777ad820c6659d52e60bbdd36bf5ff/drivers/soc/qcom/wcnss_ctrl.c#L213 it can be done in device-tree on per-device basis
Another way could be to create a symlink with msm-firmware-loader. I'm not sure which way you would prefer
The text was updated successfully, but these errors were encountered: