[PATCH 7/8] ath10k-ct: Support qcom,ath10k-calibration-data-base64

Thibaut hacks at slashdirt.org
Fri Jan 6 00:39:28 PST 2023

> Le 6 janv. 2023 à 04:48, Brian Norris <computersforpeace at gmail.com> a écrit :
> On Thu, Jan 5, 2023 at 7:12 PM Stefan Lippers-Hollmann <s.l-h at gmx.de> wrote:
>> On 2023-01-06, Christian Marangi wrote:
>>> On Thu, Jan 05, 2023 at 02:03:24PM -0800, Brian Norris wrote:
>>>> On Thu, Jan 5, 2023 at 11:59 AM Brian Norris
>> [...]
>>>> Do I need to create some intermediate/stub package just to express the
>>>> dependency, or is there some better way?
>>> In theory there is [1] coreutils-base64 as a separate package but I
>>> think we have to move that to core packages as it's part of the feeds
>>> package.
> coreutils definitely works. (busybox would too, except I just can't
> get the dependency mechanics right.)
>> There would be another alternative for base64 functionality, openssl...
>> While not the lightest package, it's already available in main and
>> with DEVICE_PACKAGES a relatively low-maintenance alternative.
>> openssl enc -base64 -in foo -out foo.base64
>> openssl enc -d -base64 -in foo.base64 -out foo
> I have to throw "-A" in there apparently, since openssl is apparently
> too strict on (lack of) line wrapping in the data source, but that
> works too.
>> With root/ overlay on eMMC, this shouldn't be too heavy for this
>> kind of hardware.
> Yeah, should be no big deal on space. These devices have ~4GB storage
> [1]. Does anybody care on non-disk-space grounds? Like "lack of
> choice"? (I guess one can install multiple SSL libraries.)

Indeed. Coreutils seems like a better choice here.

As an aside (and documentation for similar cases with devices that have smaller storage), note that if you don’t want to store the extracted firmware to permanent storage, caldata_sysfsload_from_file() offers an alternative to this.

> [1] Although the default partitioning sets
> CONFIG_TARGET_ROOTFS_PARTSIZE=200, which limits the default build
> unnecessarily to ~128MiB. I still need to figure out the best way to
> fix that:

You can probably adjust this on your target-specific config, but the reason for keeping it small is to keep sysupgrade times reasonable, IIRC.


More information about the openwrt-devel mailing list