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

[Brian Norris]

On Fri, Jan 6, 2023 at 12:39 AM Thibaut <hacks at slashdirt.org> wrote:
> > Le 6 janv. 2023 à 04:48, Brian Norris <computersforpeace at gmail.com> a écrit :

> Indeed. Coreutils seems like a better choice here.

OK. So I guess I just copy/paste it back into the openwrt tree from
the packages feed, and then later clean it out of packages.git?

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

Thanks. I was trying to grok why there were at least two variants in
caldata.sh; I liked (and imitated) the caldata_sysfsload_from_file()
approach better.

> > [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,

I suppose, although that's still in the same problem space of "how to
set a CONFIG_* default from a target" -- that also can't be done in
DEVICE_PACKAGES. (And again, I'm a little new at this, so bear with
me.)

I could also just hardcode something better I guess. I see others do this:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ipq40xx/image/generic.mk;h=f92e11c797127344c6e14d6292956eeca8f048eb;hb=d3e89e69c52115d1c02f5c16a4aa6b721e003578#l103
(Build/qsdk-ipq-app-gpt)

> but the reason for keeping it small is to keep sysupgrade times reasonable, IIRC.

Ah, makes sense.

BTW, speaking of sysupgrade (and maybe this deserves a change of
Subject if this discussion goes very far): I've found that the emmc.sh
upgrade helpers still don't seem very reliable when the rootfs size
changes (and so the "f2fs loop-mounted rootfs_data appended to the
rootfs" has to move). sysupgrade can be a bit hard to debug, since you
lose access to many normal services along the way, so I'm not 100%
sure, but it seems like the two filesystems (rootfs and data/overlay)
collide, and that a separate rootfs_data partition (such as the one in
the glinet_gl-b2200 target above) would work better. Am I missing
something here? It seems that sysupgrade is very ad-hoc in openwrt,
and that eMMC/block support is still somewhat underdeveloped, so maybe
there aren't really any conventions here, and one just does whatever
works for them? I'm thinking of just adding the rootfs_data partition
to suck up the remaining GBs of disk (and maybe adding to the Google
Wifi target too), but I'm still not sure of the Best solution.

As a bonus, with a rootfs_data partition, the sysupgrade could
potentially be a lot simpler (and does not need to scale with the size
of the rootfs_data contents), because the filesystem could mostly just
stay in-place.

Brian