[PATCH 7/8] ath10k-ct: Support qcom,ath10k-calibration-data-base64
computersforpeace at gmail.com
Fri Jan 6 13:09:10 PST 2023
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()
> >  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
I could also just hardcode something better I guess. I see others do this:
> 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
More information about the openwrt-devel