Hi Dmitry,
On 8/27/24 3:18 PM, Dmitry Baryshkov wrote:
[...]
It's also not necessarily required to merge those together as we could
probably still have two different packages to avoid bringing in files we
don't need (I assume the same SoC doesn't have both a VPU 1.0 and a VPU
2.0 ?).
First of all, the original naming seems to be incorrect as
demonstrated by the new file names:
qcom/{vpu-1.0/venus.mbn => vpu/vpu20_p4.mbn} | Bin
qcom/{vpu-2.0/venus.mbn => vpu/vpu20_p1.mbn} | Bin
qcom/{vpu-3.0/vpu30_4v.mbn => vpu/vpu30_p4.mbn} | Bin
It is possible to split one file per package and let users pick up
packages one by one, but granted that the whole size of the directory
(4 different firmware files) is 4.3 MiB, it doesn't seem to make sense
to me.
4.3MiB is quite a lot if you want to be able to have a tiny filesystem :)
Well, these devices come with 64 GiB or 128 GiB UFS storage, so no
need to be that picky.
4MiB here, 4MiB there and your image is unnecessarily tens of MiB bigger
and your OTA update image is that much bigger, the initrafms/suqashfs
take that much more space in RAM, to load, to verify, etc... It's also
not because one of the devices based on this SoC has a lot of UFS
storage that all of them would.
Ok so, if this
(https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=36db650dae038be945fb04def591fc726255b09f)
is the commit doing the change, we have an issue. We also need to
maintain backward compatibility, not between different versions of
Yocto/OE but between different versions of the kernel (I assume to be
the reason of the need for backward compatibility).
See that they mention in the commit log that they provide
backwards-compatible links, we need those as well. Otherwise we may
broke older kernels we were compatible with in the past.
I did something similar to that in a previous update, c.f.
cdcfdc1dc545fe381764795ed502a3fa0a48b87a in poky.
I would suggest the following:
- keep the packages split
- add the new file in qcom/vpu for each package
- keep the venus.mbn path (which is now a symlink)
I did a simpler thing. I think it's easier and matches the intended usage.
If VPU 1.0 and VPU 2.0 FW packages are self-sufficient, I personally see
this as a regression rather than making things easier. We have split
packages, and I don't see a reason for merging them.
I'm no maintainer, so this isn't a decision I should make. Though the
symlinks absolutely need to be part of the package(s), aside from that
it's just "policy" or preference :)
Cheers,
Quentin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#203845):
https://lists.openembedded.org/g/openembedded-core/message/203845
Mute This Topic: https://lists.openembedded.org/mt/108120531/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
