On Tue, 27 Aug 2024 at 17:13, Quentin Schulz <[email protected]> wrote: > > 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.
There is little point in adding VPU firmware to the initramfs. I see your point, but still there is a boundary between splitting the firmware too much. For example, we have bigger ath10k, ath11k and ath12k packages instead of splitting them per the SoC / platform (think of ath10k-qca4019, ath10k-qca6174, etc). Looking at other examples it is pretty common to see that the whole subdir is packaged as a single package. > > >> > >> 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. The problem is that the VPU 1.0 name is misleading. According to the file name the hardware is actually 2.0. See the discussion at https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/249#note_2001158277 > > 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 :) They already are. I'll wait for additional feedback and then post v3 dropping the RDEPENDS and rogue FILES:vpu-2.0 as you suggested. -- With best wishes Dmitry
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#203848): https://lists.openembedded.org/g/openembedded-core/message/203848 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]] -=-=-=-=-=-=-=-=-=-=-=-
