[EXT] Re: [PATCH] imx: add imx8mplus platform support

[Piotr Dymacz]

Hi Andy,

On 20.09.2022 08:47, Andy Tang wrote:
> Hi Piotr,
> 
> Please look at my response about your concerns below.

See my reply below.

>> -----Original Message-----
>> From: Piotr Dymacz <pepe2k at gmail.com>
>> Sent: 2022年8月23日 19:23
>> To: Andy Tang <andy.tang at nxp.com>
>> Cc: openwrt-devel at lists.openwrt.org; Rafał Miłecki <zajec5 at gmail.com>;
>> Petr Štetiar <ynezz at true.cz>
>> Subject: Re: [EXT] Re: [PATCH] imx: add imx8mplus platform support
>> 
> [snip]
> 
>> >> > +
>> >> > +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).bin
>> >> >
>> >>
>> +PKG_SOURCE_URL:=https://eur01.safelinks.protection.outlook.com/?url=
>> >> +h
>> >> >
>> >>
>> +ttps%3A%2F%2Fwww.nxp.com%2Flgfiles%2FNMG%2FMAD%2FYOCTO%2F&
>> >> amp;data=05
>> >> >
>> >>
>> +%7C01%7Candy.tang%40nxp.com%7C3b32776df9fc458bdc3308da7f78c352
>> >> %7C686e
>> >> >
>> >>
>> +a1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637962453910142398%7C
>> >> Unknown%7
>> >> >
>> >>
>> +CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
>> >> wiLCJX
>> >> >
>> >>
>> +VCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XYCuUHEbBXHxYglYSPaox
>> >> nQVEGD0ivXF
>> >> > +Ci0MaZllnKk%3D&reserved=0
>> >> > +PKG_HASH:=ef91390da6c8a6a48c8121a5dd667de8
>> >>
>> >> OK, so a 'firmware-imx-8.15.bin' file, hosted somewhere on NXP
>> >> servers which seems to be a self-extracting package with bunch of
>> >> proprietary binary blobs and almost 700 lines license. And it asks
>> >> for EULA acceptance when
>> >> extracting:
>> >>
>> >> "Welcome to NXP firmware-imx-8.15.bin
>> >>
>> >> You need to read and accept the EULA before you can continue.
>> >>
>> >> LA_OPT_NXP_Software_License v34 February 2022 [...] "
>> >> I don't think we can accept this (Rafał, Petr, any opinions?).
>> >> Looking at other open source projects, e.g. Barebox requires users to
>> >> manually obtain and extract the firmware [1]. U-Boot documentation
>> >> for this board mentions only the DDR training and ATF firmware [2].
>> >>
>> >> Are all the blobs really required by this platform? Is there any
>> >> other, more open source friendly way to get these binary blobs?
>> > Since the license issue, these blobs have been released together.
>> > This is the only format to release these binaries even though not all of them
>> are used on a specific platform.
>> 
>> As Petr already stated, the EULA forbids re-distribution of that firmware
>> (maybe this topic should be discussed with some lawyer but that's not our job).
>> For now I don't see any (legal) way to re-distribute these binaries by OpenWrt
>> project (embedded within a pre-built image for the platform you are adding
>> support for).
> I have checked with our legal team. They say EULA doesn't forbid re-distribution the binaries.

Could you then please ask your legal team to distribute those binaries 
under different EULA and in different form, without the statements we 
pointed out before?

I'm sorry but your assurances here, at least for me, isn't enough.

> Actually we already did this on Yocto project.
> Please see:
> 1. https://git.yoctoproject.org/meta-freescale/tree/recipes-bsp/imx-sc-firmware/imx-sc-firmware_1.13.0.bb
> 2. https://git.yoctoproject.org/meta-freescale/tree/classes/fsl-eula-unpack.bbclass

See here: 
https://git.yoctoproject.org/meta-freescale/tree/classes/fsl-eula-unpack.bbclass#n113

> In this project, firmware binary was downloaded and self-extracted automatically.

With assumption that the end customer/user has read EULA and accepted it 
(manually or automatically). And the whole process of downloading, 
accepting the license and extracting binaries is done on the end user 
machine.

Based on my experience, the Yocto project doesn't host those proprietary 
binaries and doesn't share ready to use firmware images with them 
(please, correct me if I'm wrong here). Yocto is more like a platform 
for building firmware _yourself_, not a ready-to-use Linux distribution 
you could just download and install on the hardware. OpenWrt _is_ a 
Linux distribution.

> Customer should define a variable in local.conf file to indicate that the agreement is accepted although.
> So I think it should be ok too in OpenWRT project.

Sorry but for me this is still a no-go for OpenWrt.

As I wrote before, we could add a "generic" support for this platform, 
mark it as "broken" (this would result with no prebuilt images available 
for download from OpenWrt servers), with some kind of a note for users, 
with instructions (in Wiki?) how to download proprietary binaries, 
accept the license and then _manually_ build OpenWrt for the platform.

-- 
Cheers,
Piotr