| Message ID | 20240827100930.127469-1-dmitry.baryshkov@linaro.org |
|---|---|
| State | Accepted, archived |
| Commit | 3a4204b1393b46c1ee14fa9e546e19e3f250c002 |
| Headers | show |
| Series | [v2] linux-firmware: package qcom-vpu firmware | expand |
Hi Dmitry, On 8/27/24 12:09 PM, Dmitry Baryshkov via lists.openembedded.org wrote: > Release 20240811 has restructured the locations of Qualcomm VPU > firmware. Follow those changes and implement a single > linux-firmware-qcom-vpu package holding all VPU firmware files. Use > RPROVIDES to provide previously defined names. > It'd be nice to hint at the commits in linux-firmware that do this reorg for reference? 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 ?). > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > --- > > Changes since v1: > - Dropped unrelated (audio topology) change. > > --- > .../linux-firmware/linux-firmware_20240811.bb | 16 ++++++++++------ > 1 file changed, 10 insertions(+), 6 deletions(-) > > diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20240811.bb b/meta/recipes-kernel/linux-firmware/linux-firmware_20240811.bb > index b6fb0f9a4560..d55ac9267d8f 100644 > --- a/meta/recipes-kernel/linux-firmware/linux-firmware_20240811.bb > +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20240811.bb > @@ -382,7 +382,7 @@ PACKAGES =+ "${PN}-amphion-vpu-license ${PN}-amphion-vpu \ > ${PN}-qed \ > ${PN}-qcom-license ${PN}-qcom-yamato-license \ > ${PN}-qcom-venus-1.8 ${PN}-qcom-venus-4.2 ${PN}-qcom-venus-5.2 ${PN}-qcom-venus-5.4 ${PN}-qcom-venus-6.0 \ > - ${PN}-qcom-vpu-1.0 ${PN}-qcom-vpu-2.0 \ > + ${PN}-qcom-vpu \ > ${PN}-qcom-adreno-a2xx ${PN}-qcom-adreno-a3xx ${PN}-qcom-adreno-a4xx ${PN}-qcom-adreno-a530 \ > ${PN}-qcom-adreno-a630 ${PN}-qcom-adreno-a650 ${PN}-qcom-adreno-a660 ${PN}-qcom-adreno-a702 \ > ${PN}-qcom-apq8016-modem ${PN}-qcom-apq8016-wifi \ > @@ -1368,8 +1368,7 @@ LICENSE:${PN}-qcom-venus-4.2 = "Firmware-qcom" > LICENSE:${PN}-qcom-venus-5.2 = "Firmware-qcom" > LICENSE:${PN}-qcom-venus-5.4 = "Firmware-qcom" > LICENSE:${PN}-qcom-venus-6.0 = "Firmware-qcom" > -LICENSE:${PN}-qcom-vpu-1.0 = "Firmware-qcom" > -LICENSE:${PN}-qcom-vpu-2.0 = "Firmware-qcom" > +LICENSE:${PN}-qcom-vpu = "Firmware-qcom" > LICENSE:${PN}-qcom-adreno-a2xx = "Firmware-qcom Firmware-qcom-yamato" > LICENSE:${PN}-qcom-adreno-a3xx = "Firmware-qcom" > LICENSE:${PN}-qcom-adreno-a4xx = "Firmware-qcom" > @@ -1413,7 +1412,11 @@ FILES:${PN}-qcom-venus-4.2 = "${nonarch_base_libdir}/firmware/qcom/venus-4.2/*" > FILES:${PN}-qcom-venus-5.2 = "${nonarch_base_libdir}/firmware/qcom/venus-5.2/*" > FILES:${PN}-qcom-venus-5.4 = "${nonarch_base_libdir}/firmware/qcom/venus-5.4/*" > FILES:${PN}-qcom-venus-6.0 = "${nonarch_base_libdir}/firmware/qcom/venus-6.0/*" > -FILES:${PN}-qcom-vpu-1.0 = "${nonarch_base_libdir}/firmware/qcom/vpu-1.0/*" > +FILES:${PN}-qcom-vpu = " \ > + ${nonarch_base_libdir}/firmware/qcom/vpu/* \ > + ${nonarch_base_libdir}/firmware/qcom/vpu-1.0/* \ > + ${nonarch_base_libdir}/firmware/qcom/vpu-2.0/* \ > +" > FILES:${PN}-qcom-vpu-2.0 = "${nonarch_base_libdir}/firmware/qcom/vpu-2.0/*" If we're deleting qcom-vpu-* PACKAGES, then you missed this one line to delete. > FILES:${PN}-qcom-adreno-a2xx = "${nonarch_base_libdir}/firmware/qcom/leia_*.fw ${nonarch_base_libdir}/firmware/qcom/yamato_*.fw" > FILES:${PN}-qcom-adreno-a3xx = "${nonarch_base_libdir}/firmware/qcom/a3*_*.fw ${nonarch_base_libdir}/firmware/a300_*.fw" > @@ -1458,8 +1461,7 @@ RDEPENDS:${PN}-qcom-venus-4.2 = "${PN}-qcom-license" > RDEPENDS:${PN}-qcom-venus-5.2 = "${PN}-qcom-license" > RDEPENDS:${PN}-qcom-venus-5.4 = "${PN}-qcom-license" > RDEPENDS:${PN}-qcom-venus-6.0 = "${PN}-qcom-license" > -RDEPENDS:${PN}-qcom-vpu-1.0 = "${PN}-qcom-license" > -RDEPENDS:${PN}-qcom-vpu-2.0 = "${PN}-qcom-license" > +RDEPENDS:${PN}-qcom-vpu = "${PN}-qcom-license" > RDEPENDS:${PN}-qcom-adreno-a2xx = "${PN}-qcom-license ${PN}-qcom-yamato-license" > RDEPENDS:${PN}-qcom-adreno-a3xx = "${PN}-qcom-license" > RDEPENDS:${PN}-qcom-adreno-a4xx = "${PN}-qcom-license" > @@ -1503,6 +1505,8 @@ RRECOMMENDS:${PN}-qcom-sc8280xp-lenovo-x13s-adreno = "${PN}-qcom-sc8280xp-lenovo > RRECOMMENDS:${PN}-qcom-sc8280xp-lenovo-x13s-compute = "${PN}-qcom-sc8280xp-lenovo-x13s-compat" > RRECOMMENDS:${PN}-qcom-sc8280xp-lenovo-x13s-sensors = "${PN}-qcom-sc8280xp-lenovo-x13s-compat" > > +RPROVIDES:${PN}-qcom-vpu = "${PN}-qcom-vpu-1.0 ${PN}-qcom-vpu-2.0" > + I'm of the opinion this does not make sense in master branch, backward compatibility is not required in master branch so we can just not have this line and let people update their dependencies if needed. I'll let maintainers decide here what's best :) Cheers, Quentin
Hi Quentin, Excuse me, I missed your review before sending v2. On Tue, 27 Aug 2024 at 13:25, Quentin Schulz <quentin.schulz@cherry.de> wrote: > > Hi Dmitry, > > On 8/27/24 12:09 PM, Dmitry Baryshkov via lists.openembedded.org wrote: > > Release 20240811 has restructured the locations of Qualcomm VPU > > firmware. Follow those changes and implement a single > > linux-firmware-qcom-vpu package holding all VPU firmware files. Use > > RPROVIDES to provide previously defined names. > > > > It'd be nice to hint at the commits in linux-firmware that do this reorg > for reference? Ack > > 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. > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > > --- > > > > Changes since v1: > > - Dropped unrelated (audio topology) change. > > > > --- > > .../linux-firmware/linux-firmware_20240811.bb | 16 ++++++++++------ > > 1 file changed, 10 insertions(+), 6 deletions(-) > > > > diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20240811.bb b/meta/recipes-kernel/linux-firmware/linux-firmware_20240811.bb > > index b6fb0f9a4560..d55ac9267d8f 100644 > > --- a/meta/recipes-kernel/linux-firmware/linux-firmware_20240811.bb > > +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20240811.bb > > @@ -382,7 +382,7 @@ PACKAGES =+ "${PN}-amphion-vpu-license ${PN}-amphion-vpu \ > > ${PN}-qed \ > > ${PN}-qcom-license ${PN}-qcom-yamato-license \ > > ${PN}-qcom-venus-1.8 ${PN}-qcom-venus-4.2 ${PN}-qcom-venus-5.2 ${PN}-qcom-venus-5.4 ${PN}-qcom-venus-6.0 \ > > - ${PN}-qcom-vpu-1.0 ${PN}-qcom-vpu-2.0 \ > > + ${PN}-qcom-vpu \ > > ${PN}-qcom-adreno-a2xx ${PN}-qcom-adreno-a3xx ${PN}-qcom-adreno-a4xx ${PN}-qcom-adreno-a530 \ > > ${PN}-qcom-adreno-a630 ${PN}-qcom-adreno-a650 ${PN}-qcom-adreno-a660 ${PN}-qcom-adreno-a702 \ > > ${PN}-qcom-apq8016-modem ${PN}-qcom-apq8016-wifi \ > > @@ -1368,8 +1368,7 @@ LICENSE:${PN}-qcom-venus-4.2 = "Firmware-qcom" > > LICENSE:${PN}-qcom-venus-5.2 = "Firmware-qcom" > > LICENSE:${PN}-qcom-venus-5.4 = "Firmware-qcom" > > LICENSE:${PN}-qcom-venus-6.0 = "Firmware-qcom" > > -LICENSE:${PN}-qcom-vpu-1.0 = "Firmware-qcom" > > -LICENSE:${PN}-qcom-vpu-2.0 = "Firmware-qcom" > > +LICENSE:${PN}-qcom-vpu = "Firmware-qcom" > > LICENSE:${PN}-qcom-adreno-a2xx = "Firmware-qcom Firmware-qcom-yamato" > > LICENSE:${PN}-qcom-adreno-a3xx = "Firmware-qcom" > > LICENSE:${PN}-qcom-adreno-a4xx = "Firmware-qcom" > > @@ -1413,7 +1412,11 @@ FILES:${PN}-qcom-venus-4.2 = "${nonarch_base_libdir}/firmware/qcom/venus-4.2/*" > > FILES:${PN}-qcom-venus-5.2 = "${nonarch_base_libdir}/firmware/qcom/venus-5.2/*" > > FILES:${PN}-qcom-venus-5.4 = "${nonarch_base_libdir}/firmware/qcom/venus-5.4/*" > > FILES:${PN}-qcom-venus-6.0 = "${nonarch_base_libdir}/firmware/qcom/venus-6.0/*" > > -FILES:${PN}-qcom-vpu-1.0 = "${nonarch_base_libdir}/firmware/qcom/vpu-1.0/*" > > +FILES:${PN}-qcom-vpu = " \ > > + ${nonarch_base_libdir}/firmware/qcom/vpu/* \ > > + ${nonarch_base_libdir}/firmware/qcom/vpu-1.0/* \ > > + ${nonarch_base_libdir}/firmware/qcom/vpu-2.0/* \ > > +" > > FILES:${PN}-qcom-vpu-2.0 = "${nonarch_base_libdir}/firmware/qcom/vpu-2.0/*" > > If we're deleting qcom-vpu-* PACKAGES, then you missed this one line to > delete. Ack > > > FILES:${PN}-qcom-adreno-a2xx = "${nonarch_base_libdir}/firmware/qcom/leia_*.fw ${nonarch_base_libdir}/firmware/qcom/yamato_*.fw" > > FILES:${PN}-qcom-adreno-a3xx = "${nonarch_base_libdir}/firmware/qcom/a3*_*.fw ${nonarch_base_libdir}/firmware/a300_*.fw" > > @@ -1458,8 +1461,7 @@ RDEPENDS:${PN}-qcom-venus-4.2 = "${PN}-qcom-license" > > RDEPENDS:${PN}-qcom-venus-5.2 = "${PN}-qcom-license" > > RDEPENDS:${PN}-qcom-venus-5.4 = "${PN}-qcom-license" > > RDEPENDS:${PN}-qcom-venus-6.0 = "${PN}-qcom-license" > > -RDEPENDS:${PN}-qcom-vpu-1.0 = "${PN}-qcom-license" > > -RDEPENDS:${PN}-qcom-vpu-2.0 = "${PN}-qcom-license" > > +RDEPENDS:${PN}-qcom-vpu = "${PN}-qcom-license" > > RDEPENDS:${PN}-qcom-adreno-a2xx = "${PN}-qcom-license ${PN}-qcom-yamato-license" > > RDEPENDS:${PN}-qcom-adreno-a3xx = "${PN}-qcom-license" > > RDEPENDS:${PN}-qcom-adreno-a4xx = "${PN}-qcom-license" > > @@ -1503,6 +1505,8 @@ RRECOMMENDS:${PN}-qcom-sc8280xp-lenovo-x13s-adreno = "${PN}-qcom-sc8280xp-lenovo > > RRECOMMENDS:${PN}-qcom-sc8280xp-lenovo-x13s-compute = "${PN}-qcom-sc8280xp-lenovo-x13s-compat" > > RRECOMMENDS:${PN}-qcom-sc8280xp-lenovo-x13s-sensors = "${PN}-qcom-sc8280xp-lenovo-x13s-compat" > > > > +RPROVIDES:${PN}-qcom-vpu = "${PN}-qcom-vpu-1.0 ${PN}-qcom-vpu-2.0" > > + > > I'm of the opinion this does not make sense in master branch, backward > compatibility is not required in master branch so we can just not have > this line and let people update their dependencies if needed. I'll let > maintainers decide here what's best :) Yeah, let's drop it unless maintainers disagree.
Hi Dmitry, On 8/27/24 1:35 PM, Dmitry Baryshkov wrote: > Hi Quentin, > > Excuse me, I missed your review before sending v2. > > On Tue, 27 Aug 2024 at 13:25, Quentin Schulz <quentin.schulz@cherry.de> wrote: >> >> Hi Dmitry, >> >> On 8/27/24 12:09 PM, Dmitry Baryshkov via lists.openembedded.org wrote: >>> Release 20240811 has restructured the locations of Qualcomm VPU >>> firmware. Follow those changes and implement a single >>> linux-firmware-qcom-vpu package holding all VPU firmware files. Use >>> RPROVIDES to provide previously defined names. >>> >> >> It'd be nice to hint at the commits in linux-firmware that do this reorg >> for reference? > > Ack > >> >> 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 :) 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) Basically matching what I did for qcom-{qcm2290,qrb4210}-wifi? Cheers, Quentin
On Tue, 27 Aug 2024 at 14:50, Quentin Schulz <quentin.schulz@cherry.de> wrote: > > Hi Dmitry, > > On 8/27/24 1:35 PM, Dmitry Baryshkov wrote: > > Hi Quentin, > > > > Excuse me, I missed your review before sending v2. > > > > On Tue, 27 Aug 2024 at 13:25, Quentin Schulz <quentin.schulz@cherry.de> wrote: > >> > >> Hi Dmitry, > >> > >> On 8/27/24 12:09 PM, Dmitry Baryshkov via lists.openembedded.org wrote: > >>> Release 20240811 has restructured the locations of Qualcomm VPU > >>> firmware. Follow those changes and implement a single > >>> linux-firmware-qcom-vpu package holding all VPU firmware files. Use > >>> RPROVIDES to provide previously defined names. > >>> > >> > >> It'd be nice to hint at the commits in linux-firmware that do this reorg > >> for reference? > > > > Ack > > > >> > >> 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. > > 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. $ dpkg-deb -c tmp-rpb-glibc/deploy/ipk/all/linux-firmware-qcom-vpu_*ipk drwxr-xr-x root/root 0 2024-08-09 16:02 ./usr/ drwxr-xr-x root/root 0 2024-08-09 16:02 ./usr/lib/ drwxr-xr-x root/root 0 2024-08-09 16:02 ./usr/lib/firmware/ drwxr-xr-x root/root 0 2024-08-09 16:02 ./usr/lib/firmware/qcom/ drwxr-xr-x root/root 0 2024-08-09 16:02 ./usr/lib/firmware/qcom/vpu/ drwxr-xr-x root/root 0 2024-08-09 16:02 ./usr/lib/firmware/qcom/vpu-1.0/ lrwxrwxrwx root/root 0 2024-08-09 16:02 ./usr/lib/firmware/qcom/vpu-1.0/venus.mbn -> ../vpu/vpu20_p4.mbn drwxr-xr-x root/root 0 2024-08-09 16:02 ./usr/lib/firmware/qcom/vpu-2.0/ lrwxrwxrwx root/root 0 2024-08-09 16:02 ./usr/lib/firmware/qcom/vpu-2.0/venus.mbn -> ../vpu/vpu20_p1.mbn -rw-r--r-- root/root 2031620 2024-08-09 16:02 ./usr/lib/firmware/qcom/vpu/vpu20_p1.mbn -rw-r--r-- root/root 1974884 2024-08-09 16:02 ./usr/lib/firmware/qcom/vpu/vpu20_p4.mbn -rw-r--r-- root/root 2306664 2024-08-09 16:02 ./usr/lib/firmware/qcom/vpu/vpu30_p4.mbn > Basically matching what I did for qcom-{qcm2290,qrb4210}-wifi? > > Cheers, > Quentin
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
On Tue, 27 Aug 2024 at 17:13, Quentin Schulz <quentin.schulz@cherry.de> 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.
diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20240811.bb b/meta/recipes-kernel/linux-firmware/linux-firmware_20240811.bb index b6fb0f9a4560..d55ac9267d8f 100644 --- a/meta/recipes-kernel/linux-firmware/linux-firmware_20240811.bb +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20240811.bb @@ -382,7 +382,7 @@ PACKAGES =+ "${PN}-amphion-vpu-license ${PN}-amphion-vpu \ ${PN}-qed \ ${PN}-qcom-license ${PN}-qcom-yamato-license \ ${PN}-qcom-venus-1.8 ${PN}-qcom-venus-4.2 ${PN}-qcom-venus-5.2 ${PN}-qcom-venus-5.4 ${PN}-qcom-venus-6.0 \ - ${PN}-qcom-vpu-1.0 ${PN}-qcom-vpu-2.0 \ + ${PN}-qcom-vpu \ ${PN}-qcom-adreno-a2xx ${PN}-qcom-adreno-a3xx ${PN}-qcom-adreno-a4xx ${PN}-qcom-adreno-a530 \ ${PN}-qcom-adreno-a630 ${PN}-qcom-adreno-a650 ${PN}-qcom-adreno-a660 ${PN}-qcom-adreno-a702 \ ${PN}-qcom-apq8016-modem ${PN}-qcom-apq8016-wifi \ @@ -1368,8 +1368,7 @@ LICENSE:${PN}-qcom-venus-4.2 = "Firmware-qcom" LICENSE:${PN}-qcom-venus-5.2 = "Firmware-qcom" LICENSE:${PN}-qcom-venus-5.4 = "Firmware-qcom" LICENSE:${PN}-qcom-venus-6.0 = "Firmware-qcom" -LICENSE:${PN}-qcom-vpu-1.0 = "Firmware-qcom" -LICENSE:${PN}-qcom-vpu-2.0 = "Firmware-qcom" +LICENSE:${PN}-qcom-vpu = "Firmware-qcom" LICENSE:${PN}-qcom-adreno-a2xx = "Firmware-qcom Firmware-qcom-yamato" LICENSE:${PN}-qcom-adreno-a3xx = "Firmware-qcom" LICENSE:${PN}-qcom-adreno-a4xx = "Firmware-qcom" @@ -1413,7 +1412,11 @@ FILES:${PN}-qcom-venus-4.2 = "${nonarch_base_libdir}/firmware/qcom/venus-4.2/*" FILES:${PN}-qcom-venus-5.2 = "${nonarch_base_libdir}/firmware/qcom/venus-5.2/*" FILES:${PN}-qcom-venus-5.4 = "${nonarch_base_libdir}/firmware/qcom/venus-5.4/*" FILES:${PN}-qcom-venus-6.0 = "${nonarch_base_libdir}/firmware/qcom/venus-6.0/*" -FILES:${PN}-qcom-vpu-1.0 = "${nonarch_base_libdir}/firmware/qcom/vpu-1.0/*" +FILES:${PN}-qcom-vpu = " \ + ${nonarch_base_libdir}/firmware/qcom/vpu/* \ + ${nonarch_base_libdir}/firmware/qcom/vpu-1.0/* \ + ${nonarch_base_libdir}/firmware/qcom/vpu-2.0/* \ +" FILES:${PN}-qcom-vpu-2.0 = "${nonarch_base_libdir}/firmware/qcom/vpu-2.0/*" FILES:${PN}-qcom-adreno-a2xx = "${nonarch_base_libdir}/firmware/qcom/leia_*.fw ${nonarch_base_libdir}/firmware/qcom/yamato_*.fw" FILES:${PN}-qcom-adreno-a3xx = "${nonarch_base_libdir}/firmware/qcom/a3*_*.fw ${nonarch_base_libdir}/firmware/a300_*.fw" @@ -1458,8 +1461,7 @@ RDEPENDS:${PN}-qcom-venus-4.2 = "${PN}-qcom-license" RDEPENDS:${PN}-qcom-venus-5.2 = "${PN}-qcom-license" RDEPENDS:${PN}-qcom-venus-5.4 = "${PN}-qcom-license" RDEPENDS:${PN}-qcom-venus-6.0 = "${PN}-qcom-license" -RDEPENDS:${PN}-qcom-vpu-1.0 = "${PN}-qcom-license" -RDEPENDS:${PN}-qcom-vpu-2.0 = "${PN}-qcom-license" +RDEPENDS:${PN}-qcom-vpu = "${PN}-qcom-license" RDEPENDS:${PN}-qcom-adreno-a2xx = "${PN}-qcom-license ${PN}-qcom-yamato-license" RDEPENDS:${PN}-qcom-adreno-a3xx = "${PN}-qcom-license" RDEPENDS:${PN}-qcom-adreno-a4xx = "${PN}-qcom-license" @@ -1503,6 +1505,8 @@ RRECOMMENDS:${PN}-qcom-sc8280xp-lenovo-x13s-adreno = "${PN}-qcom-sc8280xp-lenovo RRECOMMENDS:${PN}-qcom-sc8280xp-lenovo-x13s-compute = "${PN}-qcom-sc8280xp-lenovo-x13s-compat" RRECOMMENDS:${PN}-qcom-sc8280xp-lenovo-x13s-sensors = "${PN}-qcom-sc8280xp-lenovo-x13s-compat" +RPROVIDES:${PN}-qcom-vpu = "${PN}-qcom-vpu-1.0 ${PN}-qcom-vpu-2.0" + LICENSE:${PN}-liquidui = "Firmware-cavium_liquidio" FILES:${PN}-liquidio = "${nonarch_base_libdir}/firmware/liquidio"
Release 20240811 has restructured the locations of Qualcomm VPU firmware. Follow those changes and implement a single linux-firmware-qcom-vpu package holding all VPU firmware files. Use RPROVIDES to provide previously defined names. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> --- Changes since v1: - Dropped unrelated (audio topology) change. --- .../linux-firmware/linux-firmware_20240811.bb | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-)