On 01/20/2018 02:56 AM, Hauke Mehrtens wrote:
On 01/20/2018 11:15 AM, Christian Lamparter wrote:
On Friday, January 19, 2018 10:06:50 PM CET Ben Greear wrote:
On 01/19/2018 01:03 PM, Christian Lamparter wrote:
On Friday, January 19, 2018 9:12:04 PM CET gree...@candelatech.com wrote:
From: Ben Greear <gree...@candelatech.com>
This will allow us to select the CT IPQ4019 firmware instead if
desired.
Signed-off-by: Ben Greear <gree...@candelatech.com>
---
package/firmware/ipq-wifi/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/firmware/ipq-wifi/Makefile
b/package/firmware/ipq-wifi/Makefile
index 519e8c9..6690248 100644
--- a/package/firmware/ipq-wifi/Makefile
+++ b/package/firmware/ipq-wifi/Makefile
@@ -20,7 +20,7 @@ define Package/ipq-wifi-default
SUBMENU:=ath10k IPQ4019 Boarddata
SECTION:=firmware
CATEGORY:=Firmware
- DEPENDS:=@TARGET_ipq806x +ath10k-firmware-qca4019
+ DEPENDS:=@TARGET_ipq806x
TITLE:=Custom Board
endef
Wait! I remember talking about this here in the RFC thread:
<https://www.mail-archive.com/lede-dev@lists.infradead.org/msg09621.html>
|Hm, this would break the WIFI in the default configuration for the
|FritzBox 4040 image. Currently it only has a dependency on the
|ipq-wifi-fritz4040. (So it will end up without a firmware-5.bin)
What gives? Are you trying to break the AVM FRITZ!Box 4040 image on purpose?
Of course I'm not trying to break anything. But, I am not sure how to
fix this properly.
I remember writing about this too. It's in the reply.
<https://www.mail-archive.com/lede-dev@lists.infradead.org/msg09626.html>
|I think there's a another way to do this. But it will require to break with
|the existing convention of adding the board-2.bin that comes with the
|firmware repository to the ath10k-firmware-qca4019 file.
|
|This way, the custom board-2.bin will stay in place when you switch/update
|the firmware-5.bin.
|
|(The board-2.bin for the reference boards can simply be packaged just like
|one of the ipq-wifi board firmwares). And furhtermore, you could provide a
|"easy to use/install" custom ipq-wifi.ipk for the board-2.bin you currently
|host on your webside.
Of course, if you have a better idea let's hear it too. You could look into
making virtual packages (Don't know, if that's a thing with opkg, or not.
So watch out!) or go a different route. I'm sure there's plenty of ways to
do it. If you come up with something, I'll be happy to test it.
Does each platform need to specifically enable a firmware target instead of
depending on a DEPENDS statement to make it work?
From what I know, the platform (ipq806x) does not add any firmware packages to
DEFAULT_PACKAGES in the target/linux/ipq806x/Makefile. It's all "per-device".
(That said, you might want to talk to Sven Eckelmann too. As he has added
the ath10k-firmware-qca4019 package to the OpenMesh a42's DEVICE_PACKAGES.
So, if ath10k-ct is selected on a a42 it will also include the (now useless)
ath10k-firmware-qca4019, right?)
Is there some other way I can provide an option for two different firmware
binaries?
The firmware binaries (i.e. firmware-X.bin) are not the problem. It's the
"board-2.bin" files that are shipped by the ath10k-firmware-qca4019/9984/..
packages.
Regards,
Christian
Why don't you just select the default non -ct firmware in the
DEVICE_PACKAGES for each board in target/linux/ipq806x/image/Makefile
and remove this dependency. Then the default images generated by build
bot will still contain them, but when you manually build an image or use
the image builder you can replace this FW with your own -ct version.
DEVICE_PACKAGES is just a default selection and not a hard dependency.
Christian, how about this option? I think this is how the rest of the
ath10k devices work, or no one would ever have been able to select
ath10k-ct firmware to begin with?
I'd like to go ahead and get my 3 patches in, and can work on splitting out
the board-2.bin options later?
Thanks,
Ben
Hauke
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
