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

Andy Tang andy.tang at nxp.com
Mon Sep 19 23:47:46 PDT 2022 

Hi Piotr,

Please look at my response about your concerns 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.
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
In this project, firmware binary was downloaded and self-extracted automatically.
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.

> 
> > If this is not acceptable, what's your suggestion for it? Let the user do this
> manually?
> 
> I don't see any other option and honestly I'm not exactly sure how this would
> work. Maybe you could describe in the Wiki how to built the image after
> manually obtaining and extracting firmware and at the same time mark the
> platform as broken in the main codebase so it won't get built automatically
> (no official pre-built images)? From what I can see, that's how other projects
> handle that kind of restrictive EULA and binary blobs... madness.
> 
> +     $(CP) $(PKG_BUILD_DIR)/$(PKG_NAME)-$(PKG_VERSION)/firmware/ddr/synopsys/* \
> +             $(STAGING_DIR_IMAGE)/$(MKIMG_DIR) endef
> +
> +$(eval $(call BuildPackage,firmware-imx))
[snip]

> > +$(eval $(call BuildPackage,firmware-imx))
> > diff --git a/package/utils/imx-mkimage/Makefile
> > b/package/utils/imx-mkimage/Makefile
> > new file mode 100644
> > index 0000000000..4ad1b18773
> > --- /dev/null
> > +++ b/package/utils/imx-mkimage/Makefile
> > @@ -0,0 +1,38 @@
> > +# SPDX-License-Identifier: GPL-2.0-only # # Copyright 2022 NXP #
> > +include $(TOPDIR)/rules.mk
> > +
> > +PKG_NAME:=imx-mkimage
> > +PKG_VERSION:=lf-5.15.5-1.0.0
> > +PKG_RELEASE:=$(AUTORELEASE)
> > +
> > +PKG_SOURCE_PROTO:=git
> >
> +PKG_SOURCE_URL:=https://eur01.safelinks.protection.outlook.com/?url=h
> >
> +ttps%3A%2F%2Fsource.codeaurora.org%2Fexternal%2Fimx%2Fimx-mkimag
> e.git
> >
> +&data=05%7C01%7Candy.tang%40nxp.com%7C3b32776df9fc458bdc3
> 308da7f7
> >
> +8c352%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637962453
> 910142398
> >
> +%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> LCJBTiI6
> >
> +Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zPKKNJ9d1
> Q44ffY5ukbQ
> > +DwV9XbaJf2qsEHPS9njrdKA%3D&reserved=0
> > +PKG_SOURCE_VERSION:=lf-5.15.5-1.0.0
> > +PKG_MIRROR_HASH:=fdb2086a1182b2c96e8c8dcfb795f004
> 
> Another fork? Any good reason to use this instead of tools/mkimage (we use
> version from U-Boot 2022.07 at the moment)? Is there anything missing in the
> upstream so that we can't use it?
The tools/mkimage can't meet our requirement. Basically repo imx-mkimage does following things:
1. pad the related binary to N-byte-alined.
2. combine u-boot-nodtb.bin + spl/u-boot-spl.bin + bl31.bin + ddr_binaries + imx8mp-evk.dtb
3. add specific head for specific boot mode to uboot
The item 1 and 2 can be done by shell script. Item 3 was done by .C file.
If we don't use our own repo, then at least 2 script file and 1 .C file were needed.
To keep compatibility, it is better to keep it.
Do you think so?

BR,
Andy
> >> > +endef
> >> > +TARGET_DEVICES += imx8mplus
> >> > diff --git a/target/linux/imx/image/mkits-multiple-config.sh
> >> > b/target/linux/imx/image/mkits-multiple-config.sh
> >> > new file mode 100755
> >> > index 0000000000..0d83f9e34d
> >> > --- /dev/null
> >> > +++ b/target/linux/imx/image/mkits-multiple-config.sh
> >>
> >> [snip]
> >>
> >> Maybe instead of introducing another copy of the same script (see the
> >> 'layerscape' target) you could reuse existing one and make some
> >> generic image commands out of it?
> > Could you please instruct me how I can reuse the script that belongs to
> other targets like this?
> 
> Have a look for example at 'mkits-qsdk-ipq-image.sh' script [1]. It's used by
> two recipes defined in image-commands.mk [2]:
> 'qsdk-ipq-factory-nand' and 'qsdk-ipq-factory-nor'. This way, we can make use
> of them within any (sub)target, like e.g. here: [3].
> 
> [1]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.
> com%2Fopenwrt%2Fopenwrt%2Fblob%2Fmaster%2Fscripts%2Fmkits-qsdk-ip
> q-image.sh&data=05%7C01%7Candy.tang%40nxp.com%7C78ef493bf7a
> e48b7c44808da84f9e6ce%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7
> C0%7C637968506098935776%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
> 7C%7C%7C&sdata=8uJRzgA75MAs0fIomFP2rfN9p7b0bk8hqzueWIqdquE
> %3D&reserved=0
> 
> [2]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.
> com%2Fopenwrt%2Fopenwrt%2Fblob%2Fmaster%2Finclude%2Fimage-comm
> ands.mk%23L455&data=05%7C01%7Candy.tang%40nxp.com%7C78ef49
> 3bf7ae48b7c44808da84f9e6ce%7C686ea1d3bc2b4c6fa92cd99c5c301635%7
> C0%7C0%7C637968506098935776%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30
> 00%7C%7C%7C&sdata=2KHqDtA0pS6i6548BhMrLEZxGAaMY0vWFTXh5
> mPhm5M%3D&reserved=0
> 
> [3]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.
> com%2Fopenwrt%2Fopenwrt%2Fblob%2Fmaster%2Ftarget%2Flinux%2Fipq4
> 0xx%2Fimage%2Fgeneric.mk%23L477&data=05%7C01%7Candy.tang%4
> 0nxp.com%7C78ef493bf7ae48b7c44808da84f9e6ce%7C686ea1d3bc2b4c6fa
> 92cd99c5c301635%7C0%7C0%7C637968506098935776%7CUnknown%7CT
> WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> JXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=nqiHfllL8Ejom%2Fi9xTrRR
> r1VSYHAU%2FUEEcuSKmEtqo0%3D&reserved=0
> 
> --
> Cheers,
> Piotr
> 
> >
> > BR,
> > Andy
> >
> >>
> >> > diff --git a/target/linux/imx/imx8/config-5.15
> >> > b/target/linux/imx/imx8/config-5.15
> >> > new file mode 100644
> >> > index 0000000000..2b6ab299a0
> >> > --- /dev/null
> >> > +++ b/target/linux/imx/imx8/config-5.15
> >> > @@ -0,0 +1,2661 @@
> >>
> >> [snip]
> >>
> >> > diff --git a/target/linux/imx/imx8/target.mk
> >> > b/target/linux/imx/imx8/target.mk new file mode 100644 index
> >> > 0000000000..f990298d80
> >> > --- /dev/null
> >> > +++ b/target/linux/imx/imx8/target.mk
> >> > @@ -0,0 +1,11 @@
> >> > +# SPDX-License-Identifier: GPL-2.0-only # # Copyright 2022 NXP
> >> > +
> >> > +ARCH:=aarch64
> >> > +BOARDNAME:=NXP i.MX8 boards
> >> > +KERNELNAME:=Image
> >> > +
> >> > +define Target/Description
> >> > +     Build firmware images for NXP imx8 boards.
> >> > +endef
> >> > diff --git
> >> > a/target/linux/imx/patches-5.15/0001-fix-the-compiling-error.patch
> >> > b/target/linux/imx/patches-5.15/0001-fix-the-compiling-error.patch
> >> > new file mode 100644
> >> > index 0000000000..bd2cd68be8
> >> > --- /dev/null
> >> > +++ b/target/linux/imx/patches-5.15/0001-fix-the-compiling-error.pa
> >> > +++ tch
> >> > @@ -0,0 +1,39 @@
> >> > +From b671acdd69098b12ff7f567b1b6211ab4f38bf20 Mon Sep 17
> 00:00:00
> >> > +2001
> >> > +From: Yuantian Tang <andy.tang at nxp.com>
> >> > +Date: Tue, 28 Jun 2022 14:26:12 +0800
> >> > +Subject: [PATCH] fix the compiling error
> >>
> >> Please, be more specific.
> >>
> >> > +
> >> > +Signed-off-by: Andy Tang <andy.tang at nxp.com>
> >> > +---
> >> > + arch/arm64/kvm/hyp/nvhe/gen-hyprel.c | 1 +
> >> > + scripts/Makefile                     | 2 +-
> >> > + 2 files changed, 2 insertions(+), 1 deletion(-)
> >> > +
> >> > +diff --git a/arch/arm64/kvm/hyp/nvhe/gen-hyprel.c
> >> > +b/arch/arm64/kvm/hyp/nvhe/gen-hyprel.c
> >> > +index 6bc88a756cb7..99506facd30e 100644
> >> > +--- a/arch/arm64/kvm/hyp/nvhe/gen-hyprel.c
> >> > ++++ b/arch/arm64/kvm/hyp/nvhe/gen-hyprel.c
> >> > +@@ -36,6 +36,7 @@
> >> > + #include <sys/types.h>
> >> > + #include <sys/stat.h>
> >> > + #include <unistd.h>
> >> > ++#include <uapi/linux/elf-em.h>
> >> > +
> >> > + #include <generated/autoconf.h>
> >> > +
> >> > +diff --git a/scripts/Makefile b/scripts/Makefile index
> >> > +9adb6d247818..7013da949282 100644
> >> > +--- a/scripts/Makefile
> >> > ++++ b/scripts/Makefile
> >> > +@@ -21,7 +21,7 @@ HOSTCFLAGS_asn1_compiler.o =
> >> > +-I$(srctree)/include HOSTCFLAGS_sign-file.o = $(CRYPTO_CFLAGS)
> >> > +HOSTLDLIBS_sign-file =
> >> > +$(CRYPTO_LIBS)  HOSTCFLAGS_extract-cert.o = $(CRYPTO_CFLAGS)
> >> > +-HOSTLDLIBS_extract-cert = $(CRYPTO_LIBS)
> >> > ++HOSTLDLIBS_extract-cert = $(CRYPTO_LIBS) -lpthread
> >> > +
> >> > + ifdef CONFIG_UNWINDER_ORC
> >> > + ifeq ($(ARCH),x86_64)
> >> > +--
> >> > +2.25.1
> >> > +
> >>
> >> [1]
> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbar
> >> eb
> ox.org%2Fdoc%2Flatest%2Fboards%2Fimx%2Fnxp-imx8mq-evk.html&d
> a
> >>
> ta=05%7C01%7Candy.tang%40nxp.com%7C3b32776df9fc458bdc3308da7f78
> >>
> c352%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63796245391
> >>
> 0142398%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> >>
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat
> >>
> a=KWtnO0mxLOUx5SgC%2B1Cha9h8ZhyUqqHP7p8vB7hLyNI%3D&reser
> >> ved=0
> >> [2]
> >>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.
> >>
> com%2Fu-boot%2Fu-boot%2Fblob%2Fmaster%2Fdoc%2Fboard%2Fnxp%2Fim
> >>
> x8mp_evk.rst&data=05%7C01%7Candy.tang%40nxp.com%7C3b32776df
> >>
> 9fc458bdc3308da7f78c352%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> >>
> 7C0%7C637962453910142398%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> >>
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
> >> %7C%7C%7C&sdata=AAm%2FwwuvUD%2FnVLCcIWFbYmGJljZkoc4q
> 9K
> >> O8G9qIkGU%3D&reserved=0
> >>
> >> --
> >> Cheers,
> >> Piotr

More information about the openwrt-devel mailing list