| Message ID | 20210105152420.26379-2-stephane.viau@oss.nxp.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | Bump NXP BSP components to 5.4.70_2.3.0 | expand |
Hello, Le 05/01/2021 à 16:24, Stephane Viau a écrit : > - Same version as NXP release 5.4.70-2.3.0 > - EULA/COPYING: update to LA_OPT_NXP_Software_License v17 > > Signed-off-by: Stephane Viau <stephane.viau@oss.nxp.com> > Reviewed-by: Gary Bisson <gary.bisson@boundarydevices.com> Not related to this patch, but why those firmware are installed to $(TARGET_DIR)/lib/firmware/imx ? Because without any change I get: coda 2040000.vpu: Direct firmware load for vpu/vpu_fw_imx6q.bin failed with error -2 coda 2040000.vpu: Falling back to sysfs fallback for: vpu/vpu_fw_imx6q.bin coda 2040000.vpu: Direct firmware load for v4l-coda960-imx6q.bin failed with error -2 coda 2040000.vpu: Falling back to sysfs fallback for: v4l-coda960-imx6q.bin coda 2040000.vpu: firmware request failed It seems that vpu directory is expected to be in "firmware" directory: $(TARGET_DIR)/lib/firmware/vpu see: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8af7779f3cbc1f6720d15f00abc797493710d1ab At least we have to create a simlink: /lib/firmware/imx/vpu -> /lib/firmware/vpu or set fw_path_para in the kernel cmdline: firmware_class.path=/lib/firmware/imx/ Best regards, Romain > --- > v2: > - Add "EULA/COPYING: update to LA_OPT_NXP_Software_License v17" in > commit log (Gary) > --- > package/freescale-imx/firmware-imx/firmware-imx.hash | 6 +++--- > package/freescale-imx/firmware-imx/firmware-imx.mk | 2 +- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/package/freescale-imx/firmware-imx/firmware-imx.hash b/package/freescale-imx/firmware-imx/firmware-imx.hash > index 3230677d49..0a717d40f5 100644 > --- a/package/freescale-imx/firmware-imx/firmware-imx.hash > +++ b/package/freescale-imx/firmware-imx/firmware-imx.hash > @@ -1,4 +1,4 @@ > # Locally calculated > -sha256 a72f70fd2ecaa58800bb88ed672fddc322ab9843ee7777eb89b82016b0aa3614 firmware-imx-8.9.bin > -sha256 a39da2e94bd8b99eaac4325633854620ea3a55145259c3a7748c610a80714cfc EULA > -sha256 69cbb76b3f10ac5a8c36f34df7bbdf50825815560c00a946fff2922365ef01a2 COPYING > +sha256 2b70f169d4065b2a7ac7a676afe24636128bd2dacc9f5230346758c3b146b2be firmware-imx-8.10.bin > +sha256 72edc2072c86d93aa1993d15d4d19d96270af3749b0108995ad50c81d1461f52 EULA > +sha256 9c16421e7c702f56756650b8ac954d34556327e598a8666e6e8f4eb3a1aa95f1 COPYING > diff --git a/package/freescale-imx/firmware-imx/firmware-imx.mk b/package/freescale-imx/firmware-imx/firmware-imx.mk > index 7d1f42f1d8..b33ffb7ee8 100644 > --- a/package/freescale-imx/firmware-imx/firmware-imx.mk > +++ b/package/freescale-imx/firmware-imx/firmware-imx.mk > @@ -4,7 +4,7 @@ > # > ################################################################################ > > -FIRMWARE_IMX_VERSION = 8.9 > +FIRMWARE_IMX_VERSION = 8.10 > FIRMWARE_IMX_SITE = $(FREESCALE_IMX_SITE) > FIRMWARE_IMX_SOURCE = firmware-imx-$(FIRMWARE_IMX_VERSION).bin > >
Hi Romain, On Tue, Jan 12, 2021 at 7:50 PM Romain Naour <romain.naour@gmail.com> wrote: > Not related to this patch, but why those firmware are installed to > $(TARGET_DIR)/lib/firmware/imx ? > > Because without any change I get: > > coda 2040000.vpu: Direct firmware load for vpu/vpu_fw_imx6q.bin failed with error -2 > coda 2040000.vpu: Falling back to sysfs fallback for: vpu/vpu_fw_imx6q.bin > coda 2040000.vpu: Direct firmware load for v4l-coda960-imx6q.bin failed with > error -2 > coda 2040000.vpu: Falling back to sysfs fallback for: v4l-coda960-imx6q.bin > coda 2040000.vpu: firmware request failed > > It seems that vpu directory is expected to be in "firmware" directory: > $(TARGET_DIR)/lib/firmware/vpu > > see: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8af7779f3cbc1f6720d15f00abc797493710d1ab > > At least we have to create a simlink: > /lib/firmware/imx/vpu -> /lib/firmware/vpu > > or set fw_path_para in the kernel cmdline: > firmware_class.path=/lib/firmware/imx/ I notice the same here on a imx53. Then I tried to change the VPU path like this: --- a/package/freescale-imx/firmware-imx/firmware-imx.mk +++ b/package/freescale-imx/firmware-imx/firmware-imx.mk @@ -116,9 +116,9 @@ endif FIRMWARE_IMX_VPU_FW_NAME = $(call qstrip,$(BR2_PACKAGE_FIRMWARE_IMX_VPU_FW_NAME)) ifneq ($(FIRMWARE_IMX_VPU_FW_NAME),) define FIRMWARE_IMX_INSTALL_TARGET_VPU_FW - mkdir -p $(TARGET_DIR)/lib/firmware/imx/vpu + mkdir -p $(TARGET_DIR)/lib/firmware/vpu cp $(@D)/firmware/vpu/vpu_fw_$(FIRMWARE_IMX_VPU_FW_NAME)*.bin \ - $(TARGET_DIR)/lib/firmware/imx/vpu/ + $(TARGET_DIR)/lib/firmware/vpu/ endef endif ,but the VPU firmware is still not found: [ 9.237801] coda 63ff4000.vpu: IRQ bit not found [ 9.291801] coda 63ff4000.vpu: Direct firmware load for vpu_fw_imx53.bin failed with error -2 [ 9.300646] coda 63ff4000.vpu: Falling back to sysfs fallback for: vpu_fw_imx53.bin done Saving random seed: [ 9.997216] random: dd: uninitialized urandom read (512 bytes read) OK Starting network: OK Welcome to Buildroot buildroot login: root # ls /lib/firmware/vpu/vpu_fw_imx53.bin /lib/firmware/vpu/vpu_fw_imx53.bin # Any ideas? Thanks, Fabio Estevam
Hi Romain,
On Tue, Jan 12, 2021 at 9:27 PM Fabio Estevam <festevam@gmail.com> wrote:
> I notice the same here on a imx53.
It works for me if I change it like this:
--- a/package/freescale-imx/firmware-imx/firmware-imx.mk
+++ b/package/freescale-imx/firmware-imx/firmware-imx.mk
@@ -116,9 +116,8 @@ endif
FIRMWARE_IMX_VPU_FW_NAME = $(call
qstrip,$(BR2_PACKAGE_FIRMWARE_IMX_VPU_FW_NAME))
ifneq ($(FIRMWARE_IMX_VPU_FW_NAME),)
define FIRMWARE_IMX_INSTALL_TARGET_VPU_FW
- mkdir -p $(TARGET_DIR)/lib/firmware/imx/vpu
cp $(@D)/firmware/vpu/vpu_fw_$(FIRMWARE_IMX_VPU_FW_NAME)*.bin \
- $(TARGET_DIR)/lib/firmware/imx/vpu/
+ $(TARGET_DIR)/lib/firmware/
endef
endif
[ 9.727308] coda 63ff4000.vpu: IRQ bit not found
[ 9.848458] coda 63ff4000.vpu: Initialized CODA7541.
[ 9.853967] coda 63ff4000.vpu: Firmware version: 1.4.50
[ 9.937682] coda 63ff4000.vpu: encoder registered as video5
[ 9.962135] coda 63ff4000.vpu: decoder registered as video6
[ 9.985276] coda 63ff4000.vpu: encoder registered as video7
[ 10.018420] coda 63ff4000.vpu: decoder registered as video8
Would the change above be acceptable? If so, I can submit it.
Thanks
Hello Fabio, Le 13/01/2021 à 01:27, Fabio Estevam a écrit : > Hi Romain, > > On Tue, Jan 12, 2021 at 7:50 PM Romain Naour <romain.naour@gmail.com> wrote: > >> Not related to this patch, but why those firmware are installed to >> $(TARGET_DIR)/lib/firmware/imx ? >> >> Because without any change I get: >> >> coda 2040000.vpu: Direct firmware load for vpu/vpu_fw_imx6q.bin failed with error -2 >> coda 2040000.vpu: Falling back to sysfs fallback for: vpu/vpu_fw_imx6q.bin >> coda 2040000.vpu: Direct firmware load for v4l-coda960-imx6q.bin failed with >> error -2 >> coda 2040000.vpu: Falling back to sysfs fallback for: v4l-coda960-imx6q.bin >> coda 2040000.vpu: firmware request failed >> >> It seems that vpu directory is expected to be in "firmware" directory: >> $(TARGET_DIR)/lib/firmware/vpu >> >> see: >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8af7779f3cbc1f6720d15f00abc797493710d1ab >> >> At least we have to create a simlink: >> /lib/firmware/imx/vpu -> /lib/firmware/vpu >> >> or set fw_path_para in the kernel cmdline: >> firmware_class.path=/lib/firmware/imx/ > > I notice the same here on a imx53. > > Then I tried to change the VPU path like this: > > --- a/package/freescale-imx/firmware-imx/firmware-imx.mk > +++ b/package/freescale-imx/firmware-imx/firmware-imx.mk > @@ -116,9 +116,9 @@ endif > FIRMWARE_IMX_VPU_FW_NAME = $(call > qstrip,$(BR2_PACKAGE_FIRMWARE_IMX_VPU_FW_NAME)) > ifneq ($(FIRMWARE_IMX_VPU_FW_NAME),) > define FIRMWARE_IMX_INSTALL_TARGET_VPU_FW > - mkdir -p $(TARGET_DIR)/lib/firmware/imx/vpu > + mkdir -p $(TARGET_DIR)/lib/firmware/vpu > cp $(@D)/firmware/vpu/vpu_fw_$(FIRMWARE_IMX_VPU_FW_NAME)*.bin \ > - $(TARGET_DIR)/lib/firmware/imx/vpu/ > + $(TARGET_DIR)/lib/firmware/vpu/ > endef > endif > > ,but the VPU firmware is still not found: > > [ 9.237801] coda 63ff4000.vpu: IRQ bit not found > [ 9.291801] coda 63ff4000.vpu: Direct firmware load for > vpu_fw_imx53.bin failed with error -2 > [ 9.300646] coda 63ff4000.vpu: Falling back to sysfs fallback for: > vpu_fw_imx53.bin There are several path supported (see the link above): [CODA_IMX53] = { .firmware = { "vpu_fw_imx53.bin", "vpu/vpu_fw_imx53.bin", "v4l-coda7541-imx53.bin" }, So with your change, the first try fail using "/lib/firmware/vpu_fw_imx53.bin". But "/lib/firmware/vpu/vpu_fw_imx53.bin" succeed. "firmware request failed" message should never appear in your dmesg log. I believe there is a confusion between firmware (such vpu firmware) and imx sdma firmware that require to be installed to "/lib/firmware/imx" directory. See: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/boot/dts/imx6qdl.dtsi?id=8af7779f3cbc1f6720d15f00abc797493710d1ab#n883 Best regards, Romain > done > Saving random seed: [ 9.997216] random: dd: uninitialized urandom > read (512 bytes read) > OK > Starting network: OK > > Welcome to Buildroot > buildroot login: root > # ls /lib/firmware/vpu/vpu_fw_imx53.bin > /lib/firmware/vpu/vpu_fw_imx53.bin > # > > Any ideas? > > Thanks, > > Fabio Estevam >
Hi Fabio, Le 13/01/2021 à 01:43, Fabio Estevam a écrit : > Hi Romain, > > On Tue, Jan 12, 2021 at 9:27 PM Fabio Estevam <festevam@gmail.com> wrote: > >> I notice the same here on a imx53. > > It works for me if I change it like this: > > --- a/package/freescale-imx/firmware-imx/firmware-imx.mk > +++ b/package/freescale-imx/firmware-imx/firmware-imx.mk > @@ -116,9 +116,8 @@ endif > FIRMWARE_IMX_VPU_FW_NAME = $(call > qstrip,$(BR2_PACKAGE_FIRMWARE_IMX_VPU_FW_NAME)) > ifneq ($(FIRMWARE_IMX_VPU_FW_NAME),) > define FIRMWARE_IMX_INSTALL_TARGET_VPU_FW > - mkdir -p $(TARGET_DIR)/lib/firmware/imx/vpu > cp $(@D)/firmware/vpu/vpu_fw_$(FIRMWARE_IMX_VPU_FW_NAME)*.bin \ > - $(TARGET_DIR)/lib/firmware/imx/vpu/ > + $(TARGET_DIR)/lib/firmware/ Here you're installing the firmware in the first supported firmware path, this allow to load the firmware on the first try. > endef > endif > > > [ 9.727308] coda 63ff4000.vpu: IRQ bit not found > [ 9.848458] coda 63ff4000.vpu: Initialized CODA7541. > [ 9.853967] coda 63ff4000.vpu: Firmware version: 1.4.50 > [ 9.937682] coda 63ff4000.vpu: encoder registered as video5 > [ 9.962135] coda 63ff4000.vpu: decoder registered as video6 > [ 9.985276] coda 63ff4000.vpu: encoder registered as video7 > [ 10.018420] coda 63ff4000.vpu: decoder registered as video8 > > Would the change above be acceptable? If so, I can submit it. I'm not sure if we should install the vpu firmware directly in "/lib/firmware/" or "/lib/firmware/vpu". Feel free to submit a patch to discuss about this change. Thanks! Best regards, Romain > > Thanks >
Hi All, > So with your change, the first try fail using "/lib/firmware/vpu_fw_imx53.bin". > But "/lib/firmware/vpu/vpu_fw_imx53.bin" succeed. > > "firmware request failed" message should never appear in your dmesg log. > > I believe there is a confusion between firmware (such vpu firmware) and imx sdma > firmware that require to be installed to "/lib/firmware/imx" directory. Not really related to this discussion about vpu fw but I also faced an issue with an imx8mq board and the SDMA firmware. # dmesg | grep sdma [ 0.178729] imx-sdma 302c0000.sdma: Direct firmware load for imx/sdma/sdma-imx7d.bin failed with error -2 [ 0.178763] imx-sdma 302c0000.sdma: Falling back to sysfs fallback for: imx/sdma/sdma-imx7d.bin [ 60.381850] imx-sdma 302c0000.sdma: external firmware not found, using ROM firmware [ 60.389889] imx-sdma 30bd0000.sdma: external firmware not found, using ROM firmware # ls /lib/firmware/imx/sdma/^C # find / -name sdma-imx7d.bin /lib/firmware/imx/sdma/sdma-imx7d.bin Has anyone an idea what is going wrong? Thank you
Hello Heiko, Le 13/01/2021 à 09:27, Heiko Thiery a écrit : > Hi All, > >> So with your change, the first try fail using "/lib/firmware/vpu_fw_imx53.bin". >> But "/lib/firmware/vpu/vpu_fw_imx53.bin" succeed. >> >> "firmware request failed" message should never appear in your dmesg log. >> >> I believe there is a confusion between firmware (such vpu firmware) and imx sdma >> firmware that require to be installed to "/lib/firmware/imx" directory. > > Not really related to this discussion about vpu fw but I also faced an > issue with an imx8mq board and the SDMA firmware. > > # dmesg | grep sdma > [ 0.178729] imx-sdma 302c0000.sdma: Direct firmware load for > imx/sdma/sdma-imx7d.bin failed with error -2 > [ 0.178763] imx-sdma 302c0000.sdma: Falling back to sysfs fallback > for: imx/sdma/sdma-imx7d.bin based on the log timing, I would say that the rootfs wasn't mounted when the imx-sdma has been probed. Try to compile the driver as a module, not bundled into the kernel image. Best regards, Romain > [ 60.381850] imx-sdma 302c0000.sdma: external firmware not found, > using ROM firmware > [ 60.389889] imx-sdma 30bd0000.sdma: external firmware not found, > using ROM firmware > # ls /lib/firmware/imx/sdma/^C > # find / -name sdma-imx7d.bin > /lib/firmware/imx/sdma/sdma-imx7d.bin > > Has anyone an idea what is going wrong? > > Thank you >
Hi Romain, On Wed, Jan 13, 2021 at 5:10 AM Romain Naour <romain.naour@gmail.com> wrote: > I'm not sure if we should install the vpu firmware directly in "/lib/firmware/" > or "/lib/firmware/vpu". Feel free to submit a patch to discuss about this change. Mainline kernels search first inside /lib/firmware and then inside /lib/firmware/vpu The NXP BSPs search the VPU firmware inside /lib/firmware/vpu, so I think we need to use this location, which can make vendor and mainline kernels happy. However, it is not working for me if I place it inside /lib/firmware/vpu with a 5.10 kernel. I will investigate this when I have a chance. Thanks
Hello Fabio, Le 13/01/2021 à 12:16, Fabio Estevam a écrit : > Hi Romain, > > On Wed, Jan 13, 2021 at 5:10 AM Romain Naour <romain.naour@gmail.com> wrote: > >> I'm not sure if we should install the vpu firmware directly in "/lib/firmware/" >> or "/lib/firmware/vpu". Feel free to submit a patch to discuss about this change. > > Mainline kernels search first inside /lib/firmware and then inside > /lib/firmware/vpu > > The NXP BSPs search the VPU firmware inside /lib/firmware/vpu, so I > think we need to use this location, which can make vendor and mainline > kernels happy. Ok for me. > > However, it is not working for me if I place it inside > /lib/firmware/vpu with a 5.10 kernel. > > I will investigate this when I have a chance. I'm using a kernel 5.10.6 on imx6 (savrelite) Before moving vpu directory: # dmesg | grep coda [ 11.805864] coda 2040000.vpu: Direct firmware load for vpu_fw_imx6q.bin failed with error -2 [ 11.814654] coda 2040000.vpu: Falling back to sysfs fallback for: vpu_fw_imx6q.bin [ 74.713145] coda 2040000.vpu: Direct firmware load for vpu/vpu_fw_imx6q.bin failed with error -2 [ 74.722182] coda 2040000.vpu: Falling back to sysfs fallback for: vpu/vpu_fw_imx6q.bin [ 136.152801] coda 2040000.vpu: Direct firmware load for v4l-coda960-imx6q.bin failed with error -2 [ 136.161972] coda 2040000.vpu: Falling back to sysfs fallback for: v4l-coda960-imx6q.bin [ 197.590983] coda 2040000.vpu: firmware request failed # uname -a Linux buildroot 5.10.6 #1 SMP Tue Jan 12 15:47:33 CET 2021 armv7l GNU/Linux After moving vpu directory to /lib/firmware/vpu and reboot: # dmesg | grep coda [ 12.206789] coda 2040000.vpu: Direct firmware load for vpu_fw_imx6q.bin failed with error -2 [ 12.215594] coda 2040000.vpu: Falling back to sysfs fallback for: vpu_fw_imx6q.bin [ 74.749483] coda 2040000.vpu: Using fallback firmware vpu/vpu_fw_imx6q.bin [ 74.772346] coda 2040000.vpu: Firmware code revision: 46076 [ 74.777985] coda 2040000.vpu: Initialized CODA960. [ 74.783247] coda 2040000.vpu: Firmware version: 3.1.1 [ 74.790424] coda 2040000.vpu: encoder registered as video8 [ 74.796587] coda 2040000.vpu: decoder registered as video9 [ 74.809556] coda 2040000.vpu: encoder registered as video10 [ 74.823956] coda 2040000.vpu: decoder registered as video11 # uname -a Linux buildroot 5.10.6 #1 SMP Tue Jan 12 15:47:33 CET 2021 armv7l GNU/Linux I don't know why it doesn't work for you. Best regards, Romain > > Thanks > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot >
Hi Romain,
On Wed, Jan 13, 2021 at 8:31 AM Romain Naour <romain.naour@smile.fr> wrote:
> I don't know why it doesn't work for you.
It's working now. I just had to wait longer :-) The second path is
searched after approximately 75 seconds.
I will submit a patch changing the VPU path to /lib/firmware/vpu.
Thanks
Hi Romain, Am Mi., 13. Jan. 2021 um 09:39 Uhr schrieb Romain Naour <romain.naour@smile.fr>: > > Hello Heiko, > > Le 13/01/2021 à 09:27, Heiko Thiery a écrit : > > Hi All, > > > >> So with your change, the first try fail using "/lib/firmware/vpu_fw_imx53.bin". > >> But "/lib/firmware/vpu/vpu_fw_imx53.bin" succeed. > >> > >> "firmware request failed" message should never appear in your dmesg log. > >> > >> I believe there is a confusion between firmware (such vpu firmware) and imx sdma > >> firmware that require to be installed to "/lib/firmware/imx" directory. > > > > Not really related to this discussion about vpu fw but I also faced an > > issue with an imx8mq board and the SDMA firmware. > > > > # dmesg | grep sdma > > [ 0.178729] imx-sdma 302c0000.sdma: Direct firmware load for > > imx/sdma/sdma-imx7d.bin failed with error -2 > > [ 0.178763] imx-sdma 302c0000.sdma: Falling back to sysfs fallback > > for: imx/sdma/sdma-imx7d.bin > > based on the log timing, I would say that the rootfs wasn't mounted when the > imx-sdma has been probed. > > Try to compile the driver as a module, not bundled into the kernel image. Then I misunderstand the mechanism. I thought it would be retried after 60 Seconds. I will try to compile it as a module and not builtin. Thank you.
Hello Heiko, Le 13/01/2021 à 12:56, Heiko Thiery a écrit : > Hi Romain, > > Am Mi., 13. Jan. 2021 um 09:39 Uhr schrieb Romain Naour <romain.naour@smile.fr>: >> >> Hello Heiko, >> >> Le 13/01/2021 à 09:27, Heiko Thiery a écrit : >>> Hi All, >>> >>>> So with your change, the first try fail using "/lib/firmware/vpu_fw_imx53.bin". >>>> But "/lib/firmware/vpu/vpu_fw_imx53.bin" succeed. >>>> >>>> "firmware request failed" message should never appear in your dmesg log. >>>> >>>> I believe there is a confusion between firmware (such vpu firmware) and imx sdma >>>> firmware that require to be installed to "/lib/firmware/imx" directory. >>> >>> Not really related to this discussion about vpu fw but I also faced an >>> issue with an imx8mq board and the SDMA firmware. >>> >>> # dmesg | grep sdma >>> [ 0.178729] imx-sdma 302c0000.sdma: Direct firmware load for >>> imx/sdma/sdma-imx7d.bin failed with error -2 >>> [ 0.178763] imx-sdma 302c0000.sdma: Falling back to sysfs fallback >>> for: imx/sdma/sdma-imx7d.bin >> >> based on the log timing, I would say that the rootfs wasn't mounted when the >> imx-sdma has been probed. >> >> Try to compile the driver as a module, not bundled into the kernel image. > > Then I misunderstand the mechanism. I thought it would be retried > after 60 Seconds. I will try to compile it as a module and not > builtin. For some reason it doesn't seems to try again... It you want to compile the driver into the kernel, you may want to use CONFIG_EXTRA_FIRMWARE to add the firmware blob into the kernel image. But you have to be careful with the license. Best regards, Romain > > Thank you. >
Hi Stephane, Le 05/01/2021 à 16:24, Stephane Viau a écrit : > - Same version as NXP release 5.4.70-2.3.0 > - EULA/COPYING: update to LA_OPT_NXP_Software_License v17 > > Signed-off-by: Stephane Viau <stephane.viau@oss.nxp.com> > Reviewed-by: Gary Bisson <gary.bisson@boundarydevices.com> Still not related to this version bump but the sdma firmwares for imx[6,7,8] are provided by two packages: firmware-imx and linux-firmware $ sha256sum ./firmware-imx-8.10/firmware/sdma/sdma-imx6q.bin 7790c161b7e013a9dbcbffb17cc5d4cb63d952949a505647e4679f02d04c4784 ./firmware-imx-8.10/firmware/sdma/sdma-imx6q.bin $ sha256sum ./linux-firmware-20201022/imx/sdma/sdma-imx6q.bin 7790c161b7e013a9dbcbffb17cc5d4cb63d952949a505647e4679f02d04c4784 ./linux-firmware-20201022/imx/sdma/sdma-imx6q.bin We have two options: BR2_PACKAGE_FIRMWARE_IMX_SDMA_FW_NAME and BR2_PACKAGE_LINUX_FIRMWARE_IMX_SDMA The only difference is that firmware-imx provide firmware for old imx cpus. $ ls linux-firmware-20201022/imx/sdma/sdma-imx sdma-imx6q.bin sdma-imx7d.bin $ ls firmware-imx-8.10/firmware/sdma/sdma-imx sdma-imx25-to1.bin sdma-imx31-to1.bin sdma-imx31-to2.bin sdma-imx35-to1.bin sdma-imx35-to2.bin sdma-imx51-to3.bin sdma-imx53-to1.bin sdma-imx6q.bin sdma-imx7d.bin Maybe we can keep one of firmware provider. Best regards, Romain > --- > v2: > - Add "EULA/COPYING: update to LA_OPT_NXP_Software_License v17" in > commit log (Gary) > --- > package/freescale-imx/firmware-imx/firmware-imx.hash | 6 +++--- > package/freescale-imx/firmware-imx/firmware-imx.mk | 2 +- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/package/freescale-imx/firmware-imx/firmware-imx.hash b/package/freescale-imx/firmware-imx/firmware-imx.hash > index 3230677d49..0a717d40f5 100644 > --- a/package/freescale-imx/firmware-imx/firmware-imx.hash > +++ b/package/freescale-imx/firmware-imx/firmware-imx.hash > @@ -1,4 +1,4 @@ > # Locally calculated > -sha256 a72f70fd2ecaa58800bb88ed672fddc322ab9843ee7777eb89b82016b0aa3614 firmware-imx-8.9.bin > -sha256 a39da2e94bd8b99eaac4325633854620ea3a55145259c3a7748c610a80714cfc EULA > -sha256 69cbb76b3f10ac5a8c36f34df7bbdf50825815560c00a946fff2922365ef01a2 COPYING > +sha256 2b70f169d4065b2a7ac7a676afe24636128bd2dacc9f5230346758c3b146b2be firmware-imx-8.10.bin > +sha256 72edc2072c86d93aa1993d15d4d19d96270af3749b0108995ad50c81d1461f52 EULA > +sha256 9c16421e7c702f56756650b8ac954d34556327e598a8666e6e8f4eb3a1aa95f1 COPYING > diff --git a/package/freescale-imx/firmware-imx/firmware-imx.mk b/package/freescale-imx/firmware-imx/firmware-imx.mk > index 7d1f42f1d8..b33ffb7ee8 100644 > --- a/package/freescale-imx/firmware-imx/firmware-imx.mk > +++ b/package/freescale-imx/firmware-imx/firmware-imx.mk > @@ -4,7 +4,7 @@ > # > ################################################################################ > > -FIRMWARE_IMX_VERSION = 8.9 > +FIRMWARE_IMX_VERSION = 8.10 > FIRMWARE_IMX_SITE = $(FREESCALE_IMX_SITE) > FIRMWARE_IMX_SOURCE = firmware-imx-$(FIRMWARE_IMX_VERSION).bin > >
>Hi Stephane, Hi Romain, >Le 05/01/2021 à 16:24, Stephane Viau a écrit : >> - Same version as NXP release 5.4.70-2.3.0 >> - EULA/COPYING: update to LA_OPT_NXP_Software_License v17 >> >> Signed-off-by: Stephane Viau <stephane.viau@oss.nxp.com> >> Reviewed-by: Gary Bisson <gary.bisson@boundarydevices.com> > >Still not related to this version bump but the sdma firmwares for imx[6,7,8] are >provided by two packages: firmware-imx and linux-firmware > >$ sha256sum ./firmware-imx-8.10/firmware/sdma/sdma-imx6q.bin >7790c161b7e013a9dbcbffb17cc5d4cb63d952949a505647e4679f02d04c4784 >./firmware-imx-8.10/firmware/sdma/sdma-imx6q.bin > >$ sha256sum ./linux-firmware-20201022/imx/sdma/sdma-imx6q.bin >7790c161b7e013a9dbcbffb17cc5d4cb63d952949a505647e4679f02d04c4784 >./linux-firmware-20201022/imx/sdma/sdma-imx6q.bin > >We have two options: BR2_PACKAGE_FIRMWARE_IMX_SDMA_FW_NAME and >BR2_PACKAGE_LINUX_FIRMWARE_IMX_SDMA I don't know the whole history behind the presence of both options but what I know is that some effort has been put in over the last 6 months or so to clean up the package/freescale-imx/firmware-imx, including the logic behind "when to fetch the sdma firmware?" (BR2_PACKAGE_FIRMWARE_IMX_NEEDS_SDMA_FW). > >The only difference is that firmware-imx provide firmware for old imx cpus. > >$ ls linux-firmware-20201022/imx/sdma/sdma-imx >sdma-imx6q.bin sdma-imx7d.bin > >$ ls firmware-imx-8.10/firmware/sdma/sdma-imx >sdma-imx25-to1.bin sdma-imx31-to1.bin sdma-imx31-to2.bin sdma-imx35-to1.bin >sdma-imx35-to2.bin sdma-imx51-to3.bin sdma-imx53-to1.bin sdma-imx6q.bin >sdma-imx7d.bin > >Maybe we can keep one of firmware provider. If a choice must be made, I'd pick the former option rather than the latter... but that's just my opinion. BR, Stephane. > >Best regards, >Romain
Hi Stephane, Le 16/01/2021 à 22:31, Stephane Viau (OSS) a écrit : > >> Hi Stephane, > > Hi Romain, > >> Le 05/01/2021 à 16:24, Stephane Viau a écrit : >>> - Same version as NXP release 5.4.70-2.3.0 >>> - EULA/COPYING: update to LA_OPT_NXP_Software_License v17 >>> >>> Signed-off-by: Stephane Viau <stephane.viau@oss.nxp.com> >>> Reviewed-by: Gary Bisson <gary.bisson@boundarydevices.com> >> >> Still not related to this version bump but the sdma firmwares for imx[6,7,8] are >> provided by two packages: firmware-imx and linux-firmware >> >> $ sha256sum ./firmware-imx-8.10/firmware/sdma/sdma-imx6q.bin >> 7790c161b7e013a9dbcbffb17cc5d4cb63d952949a505647e4679f02d04c4784 >> ./firmware-imx-8.10/firmware/sdma/sdma-imx6q.bin >> >> $ sha256sum ./linux-firmware-20201022/imx/sdma/sdma-imx6q.bin >> 7790c161b7e013a9dbcbffb17cc5d4cb63d952949a505647e4679f02d04c4784 >> ./linux-firmware-20201022/imx/sdma/sdma-imx6q.bin >> >> We have two options: BR2_PACKAGE_FIRMWARE_IMX_SDMA_FW_NAME and >> BR2_PACKAGE_LINUX_FIRMWARE_IMX_SDMA > > I don't know the whole history behind the presence of both options but > what I know is that some effort has been put in over the last 6 months or so to > clean up the package/freescale-imx/firmware-imx, including the logic behind "when > to fetch the sdma firmware?" (BR2_PACKAGE_FIRMWARE_IMX_NEEDS_SDMA_FW). BR2_PACKAGE_LINUX_FIRMWARE_IMX_SDMA has been added back in 2017: https://git.buildroot.net/buildroot/commit/?id=b87eec6555dd716d051285d7314d55143578dd63 But indeed, the firmware-imx package install sdma firmware since the package has been added back in 2012: https://git.buildroot.net/buildroot/commit/?id=22001201ded95850f0f9388f26333c077230b6c6 > >> >> The only difference is that firmware-imx provide firmware for old imx cpus. >> >> $ ls linux-firmware-20201022/imx/sdma/sdma-imx >> sdma-imx6q.bin sdma-imx7d.bin >> >> $ ls firmware-imx-8.10/firmware/sdma/sdma-imx >> sdma-imx25-to1.bin sdma-imx31-to1.bin sdma-imx31-to2.bin sdma-imx35-to1.bin >> sdma-imx35-to2.bin sdma-imx51-to3.bin sdma-imx53-to1.bin sdma-imx6q.bin >> sdma-imx7d.bin >> >> Maybe we can keep one of firmware provider. > > If a choice must be made, I'd pick the former option rather than the latter... > but that's just my opinion. Fabio, do you have an opinion ? It seems BR2_PACKAGE_LINUX_FIRMWARE_IMX_SDMA install the same firmware than the one provided by firmware-imx package. Also BR2_PACKAGE_LINUX_FIRMWARE_IMX_SDMA in not used by any in-tree defconfigs. If you're ok, we should remove it. Best regards, Romain > > BR, > Stephane. > >> >> Best regards, >> Romain
Hi Romain, On Sat, Jan 16, 2021 at 7:45 PM Romain Naour <romain.naour@gmail.com> wrote: > Fabio, do you have an opinion ? > > It seems BR2_PACKAGE_LINUX_FIRMWARE_IMX_SDMA install the same firmware than the > one provided by firmware-imx package. Also BR2_PACKAGE_LINUX_FIRMWARE_IMX_SDMA > in not used by any in-tree defconfigs. > > If you're ok, we should remove it. Yes, agree. Only having the firmware-imx package is enough. Thanks
diff --git a/package/freescale-imx/firmware-imx/firmware-imx.hash b/package/freescale-imx/firmware-imx/firmware-imx.hash index 3230677d49..0a717d40f5 100644 --- a/package/freescale-imx/firmware-imx/firmware-imx.hash +++ b/package/freescale-imx/firmware-imx/firmware-imx.hash @@ -1,4 +1,4 @@ # Locally calculated -sha256 a72f70fd2ecaa58800bb88ed672fddc322ab9843ee7777eb89b82016b0aa3614 firmware-imx-8.9.bin -sha256 a39da2e94bd8b99eaac4325633854620ea3a55145259c3a7748c610a80714cfc EULA -sha256 69cbb76b3f10ac5a8c36f34df7bbdf50825815560c00a946fff2922365ef01a2 COPYING +sha256 2b70f169d4065b2a7ac7a676afe24636128bd2dacc9f5230346758c3b146b2be firmware-imx-8.10.bin +sha256 72edc2072c86d93aa1993d15d4d19d96270af3749b0108995ad50c81d1461f52 EULA +sha256 9c16421e7c702f56756650b8ac954d34556327e598a8666e6e8f4eb3a1aa95f1 COPYING diff --git a/package/freescale-imx/firmware-imx/firmware-imx.mk b/package/freescale-imx/firmware-imx/firmware-imx.mk index 7d1f42f1d8..b33ffb7ee8 100644 --- a/package/freescale-imx/firmware-imx/firmware-imx.mk +++ b/package/freescale-imx/firmware-imx/firmware-imx.mk @@ -4,7 +4,7 @@ # ################################################################################ -FIRMWARE_IMX_VERSION = 8.9 +FIRMWARE_IMX_VERSION = 8.10 FIRMWARE_IMX_SITE = $(FREESCALE_IMX_SITE) FIRMWARE_IMX_SOURCE = firmware-imx-$(FIRMWARE_IMX_VERSION).bin