search

msm8916-mainline / linux

Linux mainline kernel fork for various Qualcomm MSM8909/MSM8916/MSM8939 devices
https://wiki.postmarketos.org/wiki/MSM8916_Mainlining
Other
159 stars 125 forks source link

consider changing paths for WCNSS_qcom_wlan_nv.bin #339

Open jenneron opened 1 year ago

jenneron commented 1 year ago

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

TravMurav commented 1 year ago

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...

TravMurav commented 1 year ago

(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.

185264646 commented 10 months ago

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...

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.