[Buildroot] [PATCH 1/1] package/imx-sc-firmware: bump to version 1.2.1

[Buildroot] [PATCH 1/1] package/imx-sc-firmware: bump to version 1.2.1

[Julien Olivain]

This version is aligned with i.MX NXP BSP components version
rel_imx_4.14.98_2.0.0_ga

This patch also add the hash file.

Signed-off-by: Julien Olivain <juju@cotds.org>
---
 package/freescale-imx/imx-sc-firmware/imx-sc-firmware.hash | 4 ++++
 package/freescale-imx/imx-sc-firmware/imx-sc-firmware.mk   | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)
 create mode 100644 package/freescale-imx/imx-sc-firmware/imx-sc-firmware.hash

diff --git a/package/freescale-imx/imx-sc-firmware/imx-sc-firmware.hash b/package/freescale-imx/imx-sc-firmware/imx-sc-firmware.hash
new file mode 100644
index 0000000000..013201911b
--- /dev/null
+++ b/package/freescale-imx/imx-sc-firmware/imx-sc-firmware.hash
@@ -0,0 +1,4 @@
+# Locally calculated
+sha256 c7b8fe249ba529d85bfe8540e073b73e4fcdf65ee56022c319e53e0065ff1549  imx-sc-firmware-1.2.1.bin
+sha256 69d19847bac9af7f9e832170a15138f5ef144d8064413434114d75a68982cc9c  EULA
+sha256 6467f2e81d06b19fe541de49bdba32a9a205e8d1c230220fe24247b48672cb46  COPYING
diff --git a/package/freescale-imx/imx-sc-firmware/imx-sc-firmware.mk b/package/freescale-imx/imx-sc-firmware/imx-sc-firmware.mk
index fac20d0c6f..cb4e046b8a 100644
--- a/package/freescale-imx/imx-sc-firmware/imx-sc-firmware.mk
+++ b/package/freescale-imx/imx-sc-firmware/imx-sc-firmware.mk
@@ -4,7 +4,7 @@
 #
 ################################################################################
 
-IMX_SC_FIRMWARE_VERSION = 1.0
+IMX_SC_FIRMWARE_VERSION = 1.2.1
 IMX_SC_FIRMWARE_SITE = $(FREESCALE_IMX_SITE)
 IMX_SC_FIRMWARE_SOURCE = imx-sc-firmware-$(IMX_SC_FIRMWARE_VERSION).bin
 
-- 
2.24.1

[Buildroot] [PATCH 1/1] package/imx-sc-firmware: bump to version 1.2.1

[Fabio Estevam]

Hi Julien,

On Wed, Dec 18, 2019 at 10:05 AM Julien Olivain <juju@cotds.org> wrote:
>
> This version is aligned with i.MX NXP BSP components version
> rel_imx_4.14.98_2.0.0_ga
>
> This patch also add the hash file.
>
> Signed-off-by: Julien Olivain <juju@cotds.org>

...
> -IMX_SC_FIRMWARE_VERSION = 1.0
> +IMX_SC_FIRMWARE_VERSION = 1.2.1

As per the 4.14.98 BSP Release notes (Rev. L4.14.98_2.2.0, 4 November
2019) the imx-sc-firmware used is 1.2.2.

[Buildroot] [PATCH 1/1] package/imx-sc-firmware: bump to version 1.2.1

[Julien Olivain]

Hi Fabio,

On 2019-12-18 14:10, Fabio Estevam wrote:
> Hi Julien,
> 
> On Wed, Dec 18, 2019 at 10:05 AM Julien Olivain <juju@cotds.org> wrote:
>> 
>> This version is aligned with i.MX NXP BSP components version
>> rel_imx_4.14.98_2.0.0_ga
>> 
>> This patch also add the hash file.
>> 
>> Signed-off-by: Julien Olivain <juju@cotds.org>
> 
> ...
>> -IMX_SC_FIRMWARE_VERSION = 1.0
>> +IMX_SC_FIRMWARE_VERSION = 1.2.1
> 
> As per the 4.14.98 BSP Release notes (Rev. L4.14.98_2.2.0, 4 November
> 2019) the imx-sc-firmware used is 1.2.2.

As per:
https://source.codeaurora.org/external/imx/meta-fsl-bsp-release/tree/imx/meta-bsp/recipes-bsp/imx-sc-firmware?h=sumo-4.14.98-2.0.0_ga

For 4.14.98_2.0.0_ga, imx-sc-firmware is 1.2.1.
imx-sc-firmware is 1.2.2 is for 4.14.98_2.2.0.

Since the rest of the components are on 4.14.98_2.0.0_ga, I would really
suggest 1.2.1.

Best regards,

Julien.

[Buildroot] [PATCH 1/1] package/imx-sc-firmware: bump to version 1.2.1

[Fabio Estevam]

On Wed, Dec 18, 2019 at 10:23 AM Julien Olivain <juju@cotds.org> wrote:

> As per:
> https://source.codeaurora.org/external/imx/meta-fsl-bsp-release/tree/imx/meta-bsp/recipes-bsp/imx-sc-firmware?h=sumo-4.14.98-2.0.0_ga
>
> For 4.14.98_2.0.0_ga, imx-sc-firmware is 1.2.1.
> imx-sc-firmware is 1.2.2 is for 4.14.98_2.2.0.
>
> Since the rest of the components are on 4.14.98_2.0.0_ga, I would really
> suggest 1.2.1.

Correct, the NXP Release Notes on the web is for 4.14.98_2.2.0.

So using 1.2.1 is fine then.

Shouldn't IMX_SC_FIRMWARE_VERSION be passed via board defconfig instead?

Currently we are forcing the same IMX_SC_FIRMWARE_VERSION for all imx8
boards, which is not ideal because we may have imx8 boards running
4.14.78, others 4.14.98, others 4.19.35, etc

We cannot force all of them to be using the same kernel versions, so I
think we should allow the possibility to pass IMX_SC_FIRMWARE_VERSION
via board defconfig.

What do you think?

Thanks

[Buildroot] [PATCH 1/1] package/imx-sc-firmware: bump to version 1.2.1

[Fabio Estevam]

On Wed, Dec 18, 2019 at 10:05 AM Julien Olivain <juju@cotds.org> wrote:
>
> This version is aligned with i.MX NXP BSP components version
> rel_imx_4.14.98_2.0.0_ga
>
> This patch also add the hash file.
>
> Signed-off-by: Julien Olivain <juju@cotds.org>

Reviewed-by: Fabio Estevam <festevam@gmail.com>

[Buildroot] [PATCH 1/1] package/imx-sc-firmware: bump to version 1.2.1

[Julien Olivain]

Hi Fabio, All,

On 2019-12-18 14:27, Fabio Estevam wrote:
> On Wed, Dec 18, 2019 at 10:23 AM Julien Olivain <juju@cotds.org> wrote:
> 
>> As per:
>> https://source.codeaurora.org/external/imx/meta-fsl-bsp-release/tree/imx/meta-bsp/recipes-bsp/imx-sc-firmware?h=sumo-4.14.98-2.0.0_ga
>> 
>> For 4.14.98_2.0.0_ga, imx-sc-firmware is 1.2.1.
>> imx-sc-firmware is 1.2.2 is for 4.14.98_2.2.0.
>> 
>> Since the rest of the components are on 4.14.98_2.0.0_ga, I would 
>> really
>> suggest 1.2.1.
> 
> Correct, the NXP Release Notes on the web is for 4.14.98_2.2.0.
> 
> So using 1.2.1 is fine then.
> 
> Shouldn't IMX_SC_FIRMWARE_VERSION be passed via board defconfig 
> instead?
> 
> Currently we are forcing the same IMX_SC_FIRMWARE_VERSION for all imx8
> boards, which is not ideal because we may have imx8 boards running
> 4.14.78, others 4.14.98, others 4.19.35, etc
> 
> We cannot force all of them to be using the same kernel versions, so I
> think we should allow the possibility to pass IMX_SC_FIRMWARE_VERSION
> via board defconfig.
> 
> What do you think?

   I agree with you that we can't really force a single version for all
boards. Exposing a choice of version (like for Kernel, U-Boot, ATF)
seems a good trade-of (this is what I had in mind in [1]).

   For i.MX packages, several packages are in that case: I think mainly
about imx-sc-firmware, firmware-imx and imx-gpu-viv.

   The only problem I see right now is that from one version to
another, the build recipe might slightly change. We saw that recently
in [2]. This means we can't have a single recipe and a free
_CUSTOM_VERSION config option.

What about having a KConfig "choice" list of few supported versions,
also showing NXP BSP name, to help i.MX defconfig maintainers to
select the right version ? That would allow the package recipe to
adjust commands for a given version.

For example, for the imx-sc-firmware, the list of choices would be:
- 1.1.4 (4.14.78_1.0.0)
- 1.2.1 (4.14.98_2.0.0)
- 1.2.2 (4.19.35_1.0.0)
- 1.2.7.1 (4.19.35_1.1.0)

What do you think about this approach?

If you agree, I could give a try to write patches for
imx-sc-firmware package, to see how it goes...

> Thanks

Best regards,

Julien.

[1] 
http://lists.busybox.net/pipermail/buildroot/2019-December/268135.html
[2] 
http://lists.busybox.net/pipermail/buildroot/2019-December/269280.html

[Buildroot] [PATCH 1/1] package/imx-sc-firmware: bump to version 1.2.1

[Fabio Estevam]

Hi Julien,

On Wed, Dec 18, 2019 at 6:22 PM Julien Olivain <juju@cotds.org> wrote:

>    I agree with you that we can't really force a single version for all
> boards. Exposing a choice of version (like for Kernel, U-Boot, ATF)
> seems a good trade-of (this is what I had in mind in [1]).
>
>    For i.MX packages, several packages are in that case: I think mainly
> about imx-sc-firmware, firmware-imx and imx-gpu-viv.
>
>    The only problem I see right now is that from one version to
> another, the build recipe might slightly change. We saw that recently
> in [2]. This means we can't have a single recipe and a free
> _CUSTOM_VERSION config option.
>
> What about having a KConfig "choice" list of few supported versions,
> also showing NXP BSP name, to help i.MX defconfig maintainers to
> select the right version ? That would allow the package recipe to
> adjust commands for a given version.
>
> For example, for the imx-sc-firmware, the list of choices would be:
> - 1.1.4 (4.14.78_1.0.0)
> - 1.2.1 (4.14.98_2.0.0)
> - 1.2.2 (4.19.35_1.0.0)
> - 1.2.7.1 (4.19.35_1.1.0)
>
> What do you think about this approach?

Yes, I like this idea.

Thanks

[Buildroot] [PATCH 1/1] package/imx-sc-firmware: bump to version 1.2.1

[Thomas Petazzoni]

On Wed, 18 Dec 2019 14:04:29 +0100
Julien Olivain <juju@cotds.org> wrote:

> This version is aligned with i.MX NXP BSP components version
> rel_imx_4.14.98_2.0.0_ga
> 
> This patch also add the hash file.
> 
> Signed-off-by: Julien Olivain <juju@cotds.org>
> ---
>  package/freescale-imx/imx-sc-firmware/imx-sc-firmware.hash | 4 ++++
>  package/freescale-imx/imx-sc-firmware/imx-sc-firmware.mk   | 2 +-
>  2 files changed, 5 insertions(+), 1 deletion(-)
>  create mode 100644 package/freescale-imx/imx-sc-firmware/imx-sc-firmware.hash

Applied to master, thanks.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH 1/1] package/imx-sc-firmware: bump to version 1.2.1

[Thomas Petazzoni]

Hello,

On Wed, 18 Dec 2019 22:22:08 +0100
Julien Olivain <juju@cotds.org> wrote:

>    I agree with you that we can't really force a single version for all
> boards. Exposing a choice of version (like for Kernel, U-Boot, ATF)
> seems a good trade-of (this is what I had in mind in [1]).

> 
>    For i.MX packages, several packages are in that case: I think mainly
> about imx-sc-firmware, firmware-imx and imx-gpu-viv.
> 
>    The only problem I see right now is that from one version to
> another, the build recipe might slightly change. We saw that recently
> in [2]. This means we can't have a single recipe and a free
> _CUSTOM_VERSION config option.
> 
> What about having a KConfig "choice" list of few supported versions,
> also showing NXP BSP name, to help i.MX defconfig maintainers to
> select the right version ? That would allow the package recipe to
> adjust commands for a given version.
> 
> For example, for the imx-sc-firmware, the list of choices would be:
> - 1.1.4 (4.14.78_1.0.0)
> - 1.2.1 (4.14.98_2.0.0)
> - 1.2.2 (4.19.35_1.0.0)
> - 1.2.7.1 (4.19.35_1.1.0)
> 
> What do you think about this approach?

In general, we don't really like to have too much version selection for
components, because it makes the maintenance difficult, and it is also
more difficult for users as they have to know which version to use.

However, for the specific case of this firmware package, I don't really
see any other option than what you're proposing.

One question is: how does it work if one wants to use the upstream
Linux kernel?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH 1/1] package/imx-sc-firmware: bump to version 1.2.1

[Fabio Estevam]

Hi Thomas,

On Sun, Dec 22, 2019 at 10:24 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:

> One question is: how does it work if one wants to use the upstream
> Linux kernel?

I have been successfully using the NXP components from 4.19.35_1.1.0
NXP BSP (sc-firmware, AT-F, linux-firmware) with mainline kernel.

I plan to generate targets to boot  i.mx8 boards with mainline U-Boot
and mainline kernel.

Thanks

[Buildroot] [PATCH 1/1] package/imx-sc-firmware: bump to version 1.2.1

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:

Hi,

 >> For example, for the imx-sc-firmware, the list of choices would be:
 >> - 1.1.4 (4.14.78_1.0.0)
 >> - 1.2.1 (4.14.98_2.0.0)
 >> - 1.2.2 (4.19.35_1.0.0)
 >> - 1.2.7.1 (4.19.35_1.1.0)
 >> 
 >> What do you think about this approach?

 > In general, we don't really like to have too much version selection for
 > components, because it makes the maintenance difficult, and it is also
 > more difficult for users as they have to know which version to use.

 > However, for the specific case of this firmware package, I don't really
 > see any other option than what you're proposing.

 > One question is: how does it work if one wants to use the upstream
 > Linux kernel?

Agreed, presumably these crazy version dependencies between components
will get sorted out once the platform becomes a bit more mature?

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 1/1] package/imx-sc-firmware: bump to version 1.2.1

[Fabio Estevam]

Hi Peter,

On Sun, Dec 22, 2019 at 11:34 AM Peter Korsgaard <peter@korsgaard.com> wrote:

> Agreed, presumably these crazy version dependencies between components
> will get sorted out once the platform becomes a bit more mature?

Yes, I hope so too.

Currently it is painful to handle all these dependencies and hope we
can make progress on this front.

Thanks