[LEDE-DEV] [PATCH-v2 3/3] ath10k-firmware: Support CT IPQ4019 firmware.

Christian Lamparter chunkeey at gmail.com
Mon Jan 22 09:51:53 PST 2018


On Sunday, January 21, 2018 10:49:19 PM CET Ben Greear wrote:
> 
> On 01/21/2018 07:54 AM, Christian Lamparter wrote:
> > On Saturday, January 20, 2018 1:27:04 AM CET greearb at candelatech.com wrote:
> >> From: Ben Greear <greearb at candelatech.com>
> >>
> >> Initial beta release of the CT IPQ4019 firmware.  Features are
> >> similar to the CT 9984 firmware
> 
> >> +$(eval $(call BuildPackage,ath10k-firmware-qca4019-ct-htt))
> >> +$(eval $(call BuildPackage,ath10k-firmware-qca4019-ct))
> >>  $(eval $(call BuildPackage,ath10k-firmware-qca9888-ct))
> >>
> > ---
> > I applied the full series on top of the r5904 (see attached
> > diffconfig). But I ran into issues when selecting ath10k-ct
> > and ath10k-firmware-qca4019-ct during image creation.
> > So what's the recommended way to install these?
> 
> Are you able to un-select the default firmware? In that case,
> there should be no issue with the board-2.bin?
Try the diffconfig. It a multi-image built that includes all the current
qca4019 targets. From what I can see, neither kmod-ath10k or
ath10k-firmware-qca4019 can be deselected. At best kmod-ath10k
can be compiled as an installable package (=m). However 
ath10k-firmware-qca4019 will always be included (=y)
(due to the ipq-wifi packages' DEPENDS).

kconfig/menuconfig provides some information to why the packages
are being picked:

kmod-ath10k is Selected by: MODULE_DEFAULT_kmod-ath10k [=y] && \
         TARGET_PER_DEVICE_ROOTFS [=y] && m && MODULES [=y]

ath10k-firmware-qca4019 is Selected by:
  MODULE_DEFAULT_ath10k-firmware-qca4019 [=y] && TARGET_PER_DEVICE_ROOTFS [=y] \\ 
  && m && MODULES [=y] || PACKAGE_ipq-wifi-avm_fritzbox-4040 [=m] && \
  TARGET_ipq806x [=y] || PACKAGE_ipq-wifi-openmesh_a42 [=y] &&
  TARGET_ipq806x [=y] && (m && MODULES [=y] || PACKAGE_ipq-wifi-avm_fritzbox-4040 [=m]!=y)

> I expect the use case is to install exactly one of the firmware targets.
>
> If we take the board-2.bin out of the firmware install target, then users
> would somehow have to know to install some sort of board-2.bin or similar
> file, otherwise the driver still will not load.
>
> Since some boards have their own custom board-2.bin, I'm not sure how to
> automate this properly.  But, if we just assume users will select the
> right thing, then splitting board-2.bin out of the FW install target
> should be OK I guess?
I guess. Separating the board-2.bin files also has an advantage that it
will make it possible for users to update the ath10k-firmware-* package
on a deployed system without needing to reinstall the custom ipq-wifi
for their device each time.

But why not ask the ath10k-firmware package maintainer for input as well?
It could just be that a solution is just hiding in plain sight.

For example a easy solution would be just add a short note to the package
description of ath10k-firmware-qca4019-ct(-htt) like the one that was added
to ath10k-firmware-qca9984-ct: 
"This firmware conflicts with the standard 9984 firmware, so select only
one." [0] (but tailored to qca4019). This will leave it to the user to
either select/deselect the right firmware and driver combo manually.

Another possible way would be to set the "CONFLICTS" variable on the
kmod-ath10k(-ct) and all the ath10k-firmware-* packages. This would have
the advantage that the package/firmware/driver selection would be automatic.

Or maybe there's an elegant solution with "ALTERNATIVES"/"REPLACES"/"PROVIDES"/
"DEPENDS" package variables. With the kmod-ath10k-ct and ath10k-firmware-*-ct
packages at a higher priority, so they'll take precedence if selected.

... etc.

Regards,
Christian

[0] <https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/firmware/ath10k-firmware/Makefile;h=94e59537834a67e8b9d469f6a050697e6cf24789;hb=HEAD#l145>




More information about the Lede-dev mailing list