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

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

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.

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.

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

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>

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

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

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

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

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

>>>>> "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?

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