diff mbox series

[v3] mfgtools: bump revision to latest uuu version

Message ID 20190608105337.19879-1-bisson.gary@gmail.com
State Not Applicable
Headers show
Series [v3] mfgtools: bump revision to latest uuu version | expand

Commit Message

Gary Bisson June 8, 2019, 10:53 a.m. UTC 
NXP deprecated the old mfgtools code, also called mfgtools v2 although
the releases were named v0.xx.

It has been replaced by the Universal Update Utility (uuu), also called
mfgtools v3.0 although the releases are named v1.x.yy.

This new tool actually resides in the same repository in the master
branch whereas the old one is now in a 'linux' branch.

Since the old tool has issues building lately, let's switch to the new
one. Note that uuu seems to be cleaner, supports much more features
(i.MX8/8M/8QXP boot, fastboot etc..) and has a better documentation:
https://github.com/NXPmicro/mfgtools/wiki

[from Jorg's patch]
Note, that mfgtools uses git to define a version string `GIT_VERSION`.
It does so even when building from a source tarball (automatically
generated by github). The problem is, that git provides the version
information of Buildroot and mfgtools uses this version information to
do a runtime check to detect outdated command list scripts.

To fix this, we overwrite gen_ver.sh with something that simply prints a
define for `GIT_VERSION` with the mfgtools version string (preceeded by
"lib", as done in the original gen_ver.sh).

Signed-off-by: Gary Bisson <bisson.gary@gmail.com>
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
---
Changelog v3:
- inclue Jörg's version fix into this patch
- use git rev instead of tag to have the fix to Thomas' build issue
  included:
https://github.com/NXPmicro/mfgtools/commit/646e4d70

Changelog v2:
- update Config.in help text to mention tool version
- update project URL (codeauroraforum doesn't apply to NXP repositories
  now that the Qualcomm merger isn't happening)
- add README.md to license files (like before)
---
 package/mfgtools/Config.in.host | 10 ++++----
 package/mfgtools/mfgtools.hash  |  6 ++---
 package/mfgtools/mfgtools.mk    | 38 ++++++++++------------------
 package/mfgtools/readme.txt     | 45 +++++----------------------------
 4 files changed, 29 insertions(+), 70 deletions(-)

Comments

Arnout Vandecappelle June 8, 2019, 8:28 p.m. UTC | #1 
Hi Gary,

On 08/06/2019 12:53, Gary Bisson wrote:
> NXP deprecated the old mfgtools code, also called mfgtools v2 although
> the releases were named v0.xx.
> 
> It has been replaced by the Universal Update Utility (uuu), also called
> mfgtools v3.0 although the releases are named v1.x.yy.
> 
> This new tool actually resides in the same repository in the master
> branch whereas the old one is now in a 'linux' branch.
> 
> Since the old tool has issues building lately, let's switch to the new
> one. Note that uuu seems to be cleaner, supports much more features
> (i.MX8/8M/8QXP boot, fastboot etc..) and has a better documentation:
> https://github.com/NXPmicro/mfgtools/wiki

 Does it also offer the same API? If you have some scripts using mfgtools, will
they work unchanged with uuu?

 If not, then I think uuu should be an entirely new package. We could choose to
deprecate mfgtools immediately, but we'd need a legacy entry if the API has changed.

[snip]
> +2. Run the MfgTools (now called uuu) client to boot the board from USB:
>  
> +$ ./output/host/bin/uuu output/images/u-boot.imx
[snip]
> -$ ./host/bin/mfgtoolcli -l mmc -s uboot_defconfig=imx \
> -  -s dtbname=imx6q-sabrelite.dtb -s initramfs=rootfs.cpio.uboot \
> -  -s mmc=1 -p 1

 Yup, the API has definitely changed...

 So, I'm in favour of creating BR2_PACKAGE_HOST_UUU and killing
BR2_PACKAGE_HOST_MFGTOOLS.

 I marked the patch as Not Applicable in patchwork. If you convince me to do it
this way after all, we can fish it up again.

 Regards,
 Arnout
Arnout Vandecappelle June 8, 2019, 8:28 p.m. UTC | #2 
Hi Gary,

On 08/06/2019 12:53, Gary Bisson wrote:
> NXP deprecated the old mfgtools code, also called mfgtools v2 although
> the releases were named v0.xx.
> 
> It has been replaced by the Universal Update Utility (uuu), also called
> mfgtools v3.0 although the releases are named v1.x.yy.
> 
> This new tool actually resides in the same repository in the master
> branch whereas the old one is now in a 'linux' branch.
> 
> Since the old tool has issues building lately, let's switch to the new
> one. Note that uuu seems to be cleaner, supports much more features
> (i.MX8/8M/8QXP boot, fastboot etc..) and has a better documentation:
> https://github.com/NXPmicro/mfgtools/wiki

 Does it also offer the same API? If you have some scripts using mfgtools, will
they work unchanged with uuu?

 If not, then I think uuu should be an entirely new package. We could choose to
deprecate mfgtools immediately, but we'd need a legacy entry if the API has changed.

[snip]
> +2. Run the MfgTools (now called uuu) client to boot the board from USB:
>  
> +$ ./output/host/bin/uuu output/images/u-boot.imx
[snip]
> -$ ./host/bin/mfgtoolcli -l mmc -s uboot_defconfig=imx \
> -  -s dtbname=imx6q-sabrelite.dtb -s initramfs=rootfs.cpio.uboot \
> -  -s mmc=1 -p 1

 Yup, the API has definitely changed...

 So, I'm in favour of creating BR2_PACKAGE_HOST_UUU and killing
BR2_PACKAGE_HOST_MFGTOOLS.

 I marked the patch as Not Applicable in patchwork. If you convince me to do it
this way after all, we can fish it up again.

 Regards,
 Arnout
Gary Bisson June 11, 2019, 8:15 a.m. UTC | #3 
Hi Arnout,

On Sat, Jun 08, 2019 at 10:28:09PM +0200, Arnout Vandecappelle wrote:
>  Hi Gary,
> 
> On 08/06/2019 12:53, Gary Bisson wrote:
> > NXP deprecated the old mfgtools code, also called mfgtools v2 although
> > the releases were named v0.xx.
> > 
> > It has been replaced by the Universal Update Utility (uuu), also called
> > mfgtools v3.0 although the releases are named v1.x.yy.
> > 
> > This new tool actually resides in the same repository in the master
> > branch whereas the old one is now in a 'linux' branch.
> > 
> > Since the old tool has issues building lately, let's switch to the new
> > one. Note that uuu seems to be cleaner, supports much more features
> > (i.MX8/8M/8QXP boot, fastboot etc..) and has a better documentation:
> > https://github.com/NXPmicro/mfgtools/wiki
> 
>  Does it also offer the same API? If you have some scripts using mfgtools, will
> they work unchanged with uuu?
> 
>  If not, then I think uuu should be an entirely new package. We could choose to
> deprecate mfgtools immediately, but we'd need a legacy entry if the API has changed.

No the API has changed as the tool was apparently re-developed from the
ground up.

The idea of keeping the same package name although it broke the API is
that:
1- it's still in the same repository
2- NXP still mentions it as mfgtools (although sometimes calling it uuu)
  -> all new NXP releases will use that new tool

> [snip]
> > +2. Run the MfgTools (now called uuu) client to boot the board from USB:
> >  
> > +$ ./output/host/bin/uuu output/images/u-boot.imx
> [snip]
> > -$ ./host/bin/mfgtoolcli -l mmc -s uboot_defconfig=imx \
> > -  -s dtbname=imx6q-sabrelite.dtb -s initramfs=rootfs.cpio.uboot \
> > -  -s mmc=1 -p 1
> 
>  Yup, the API has definitely changed...
> 
>  So, I'm in favour of creating BR2_PACKAGE_HOST_UUU and killing
> BR2_PACKAGE_HOST_MFGTOOLS.
> 
>  I marked the patch as Not Applicable in patchwork. If you convince me to do it
> this way after all, we can fish it up again.

Ok I can do that. I'll offer another series that deprecates mfgtools and creates
a new uuu package.

Regards,
Gary
Arnout Vandecappelle June 11, 2019, 9:52 a.m. UTC | #4 
On 11/06/2019 10:15, Gary Bisson wrote:
>>  So, I'm in favour of creating BR2_PACKAGE_HOST_UUU and killing
>> BR2_PACKAGE_HOST_MFGTOOLS.
>>
>>  I marked the patch as Not Applicable in patchwork. If you convince me to do it
>> this way after all, we can fish it up again.
> 
> Ok I can do that. I'll offer another series that deprecates mfgtools and creates
> a new uuu package.

 Maybe first Peter and Thomas can confirm that this is the right approach?

 In summary: the current version of mfgtools creates a completely different
program called uuu that is used in a completely different way. In other words,
existing scripts will no longer work. Because of this, my proposal is to create
a new package for it, and move the existing mfgtools to legacy.

 Regards,
 Arnout
Thomas Petazzoni June 11, 2019, 11:07 a.m. UTC | #5 
On Tue, 11 Jun 2019 11:52:31 +0200
Arnout Vandecappelle <arnout@mind.be> wrote:

>  Maybe first Peter and Thomas can confirm that this is the right approach?
> 
>  In summary: the current version of mfgtools creates a completely different
> program called uuu that is used in a completely different way. In other words,
> existing scripts will no longer work. Because of this, my proposal is to create
> a new package for it, and move the existing mfgtools to legacy.

I agree that a new separate package is better.

Best regards,

Thomas
Yann E. MORIN June 12, 2019, 3:58 p.m. UTC | #6 
Arnout, Gary, All,

On 2019-06-11 11:52 +0200, Arnout Vandecappelle spake thusly:
> On 11/06/2019 10:15, Gary Bisson wrote:
> >>  So, I'm in favour of creating BR2_PACKAGE_HOST_UUU and killing
> >> BR2_PACKAGE_HOST_MFGTOOLS.
> >>
> >>  I marked the patch as Not Applicable in patchwork. If you convince me to do it
> >> this way after all, we can fish it up again.
> > 
> > Ok I can do that. I'll offer another series that deprecates mfgtools and creates
> > a new uuu package.
> 
>  Maybe first Peter and Thomas can confirm that this is the right approach?
> 
>  In summary: the current version of mfgtools creates a completely different
> program called uuu that is used in a completely different way. In other words,
> existing scripts will no longer work. Because of this, my proposal is to create
> a new package for it, and move the existing mfgtools to legacy.

Why ditch the older one? People are almost certain to have scripts that
rely on it, and since the new one is not a drop-in replacement, we can
keep the old one.

Regards,
Yann E. MORIN.

>  Regards,
>  Arnout
> 
> _______________________________________________
> buildroot mailing list
> buildroot@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
Gary Bisson June 12, 2019, 4:41 p.m. UTC | #7 
Hi Yann,

On Wed, Jun 12, 2019 at 05:58:44PM +0200, Yann E. MORIN wrote:
> Arnout, Gary, All,
> 
> On 2019-06-11 11:52 +0200, Arnout Vandecappelle spake thusly:
> > On 11/06/2019 10:15, Gary Bisson wrote:
> > >>  So, I'm in favour of creating BR2_PACKAGE_HOST_UUU and killing
> > >> BR2_PACKAGE_HOST_MFGTOOLS.
> > >>
> > >>  I marked the patch as Not Applicable in patchwork. If you convince me to do it
> > >> this way after all, we can fish it up again.
> > > 
> > > Ok I can do that. I'll offer another series that deprecates mfgtools and creates
> > > a new uuu package.
> > 
> >  Maybe first Peter and Thomas can confirm that this is the right approach?
> > 
> >  In summary: the current version of mfgtools creates a completely different
> > program called uuu that is used in a completely different way. In other words,
> > existing scripts will no longer work. Because of this, my proposal is to create
> > a new package for it, and move the existing mfgtools to legacy.
> 
> Why ditch the older one? People are almost certain to have scripts that
> rely on it, and since the new one is not a drop-in replacement, we can
> keep the old one.

Reasons behind that change were:
1- the current code keeps having build issues
2- the upstream project doesn't accept any patch anymore [1]
3- all NXP releases now use this new version, it doesn't provide scripts
   for the old tool any longer, even for imx6/7 releases [2]
4- the code is ugly (Windows tool ported to Linux at some point)
5- this tool is pretty much useless without imx-uuc, right now imx-uuc
   is working with both, but nothing is for sure about future uuc
   releases.

But if you feel strongly about maintaining that package on our own in BR
let me know.

Regards,
Gary

[1] https://github.com/NXPmicro/mfgtools/pull/104
[2] https://www.nxp.com/webapp/Download?colCode=imx-yocto-L4.14.98_2.0.0_ga
Yann E. MORIN June 12, 2019, 5:05 p.m. UTC | #8 
Gary, All,

On 2019-06-12 18:41 +0200, Gary Bisson spake thusly:
> On Wed, Jun 12, 2019 at 05:58:44PM +0200, Yann E. MORIN wrote:
[--SNIP--]
> > Why ditch the older one? People are almost certain to have scripts that
> > rely on it, and since the new one is not a drop-in replacement, we can
> > keep the old one.
> 
> Reasons behind that change were:
> 1- the current code keeps having build issues

14 build failures since it was introduced 1.5 years ago, that's not
really breaking all over the place either. ;-) Besides, it really
started to break in May this year, and they all happen on Xogium's
autobuilder. Bisecting should be relatively easy, there are only about
29 commits between 2019.05-rc1 (where it seems it was still working) and
1cbc8172 (the first known failure).

> 2- the upstream project doesn't accept any patch anymore [1]
> 3- all NXP releases now use this new version, it doesn't provide scripts
>    for the old tool any longer, even for imx6/7 releases [2]

Well, I'm not speaking about the upstream tools, but tools that people
will have written for their own use, which we may never have heard of.
If they use it, it works for them, so why remove it?

> 4- the code is ugly (Windows tool ported to Linux at some point)

When has upstream code quality been a concern for us? ;-)

> 5- this tool is pretty much useless without imx-uuc, right now imx-uuc
>    is working with both, but nothing is for sure about future uuc
>    releases.

Ah, that is indeed a good reason to drop it: if the imx-uuc, which we
ship for the target, needs to go hand-in-hand with mfgtools/uuu, then it
makes sense to even completely drop mfgtools.

This is actually the only reason that I find valid, and it is a
compeling reason.

So yes: rename the package to imx-uuu, and completely drop mfgtools.

Thanks for the detailed explanations!

Regards,
Yann E. MORIN.

> But if you feel strongly about maintaining that package on our own in BR
> let me know.
> 
> Regards,
> Gary
> 
> [1] https://github.com/NXPmicro/mfgtools/pull/104
> [2] https://www.nxp.com/webapp/Download?colCode=imx-yocto-L4.14.98_2.0.0_ga
diff mbox series

Patch

diff --git a/package/mfgtools/Config.in.host b/package/mfgtools/Config.in.host
index 4bbdde38e2..dd4f037b6c 100644
--- a/package/mfgtools/Config.in.host
+++ b/package/mfgtools/Config.in.host
@@ -6,9 +6,9 @@  config BR2_PACKAGE_HOST_MFGTOOLS
 	depends on BR2_arm
 	depends on BR2_HOST_GCC_AT_LEAST_4_8 # needs C++11
 	help
-	  This package contains the Freescale manufacturing tool.
-	  It is designed to program firmware to i.MX boards during
-	  production. The communication is done over USB using the
-	  Freescale UTP protocol.
+	  This package contains the NXP Universal Update Utility
+	  (MFGTools v3) for i.MX boards.
+	  It allows to load a bootloader/kernel/ramdisk over USB SDP
+	  protocol as well as sending commands to flash a storage.
 
-	  https://github.com/codeauroraforum/mfgtools
+	  https://github.com/NXPmicro/mfgtools
diff --git a/package/mfgtools/mfgtools.hash b/package/mfgtools/mfgtools.hash
index 4932a80dba..6b3771d178 100644
--- a/package/mfgtools/mfgtools.hash
+++ b/package/mfgtools/mfgtools.hash
@@ -1,4 +1,4 @@ 
 # locally computed
-sha256  055d71227d18883d6e8bc9e854c076015f9a7749820a94272e19071bf0b25c89  mfgtools-v0.02.tar.gz
-sha256  2655559a6bb1179eae514f5c7166f4ede4f2453efa9cf4dc3c045cab5d57dede  LICENSE
-sha256  0963b6e5086bf454265b0f57821a02b681d1211e40ad74c310231cb4d94815c9  README.txt
+sha256  4ac9fcbcd0df430afaaa2d520da2a434cfa102a8f7cbf1db831e2c345f9a8642  mfgtools-9360b9c2c7342f1972894cdb14eb3adcc09a47e4.tar.gz
+sha256  cc8d47f7b9260f6669ecd41c24554c552f17581d81ee8fc602c6d23edb8bf495  LICENSE
+sha256  01a4b15843de543b01fb0600eba02248273182bcf11da60d2d7736440f0995b6  README.md
diff --git a/package/mfgtools/mfgtools.mk b/package/mfgtools/mfgtools.mk
index e4663a8af9..fbcca08749 100644
--- a/package/mfgtools/mfgtools.mk
+++ b/package/mfgtools/mfgtools.mk
@@ -4,31 +4,21 @@ 
 #
 ################################################################################
 
-MFGTOOLS_VERSION = v0.02
-MFGTOOLS_SITE = $(call github,codeauroraforum,mfgtools,$(MFGTOOLS_VERSION))
-MFGTOOLS_SUBDIR = MfgToolLib
-MFGTOOLS_LICENSE = BSD-3-Clause or CPOL
-MFGTOOLS_LICENSE_FILES = LICENSE README.txt
-HOST_MFGTOOLS_DEPENDENCIES = host-libusb
+MFGTOOLS_VERSION = 9360b9c2c7342f1972894cdb14eb3adcc09a47e4
+MFGTOOLS_SITE = $(call github,NXPmicro,mfgtools,$(MFGTOOLS_VERSION))
+MFGTOOLS_LICENSE = BSD-3-Clause
+MFGTOOLS_LICENSE_FILES = LICENSE README.md
+HOST_MFGTOOLS_DEPENDENCIES = host-libusb host-bzip2 host-libzip host-zlib
 
-HOST_MFGTOOLS_CFLAGS = \
-	$(HOST_CFLAGS) $(HOST_LDFLAGS) -std=c++11 -lpthread \
-	-L$(@D)/MfgToolLib -lMfgToolLib -I$(@D)/MfgToolLib \
-	-lusb-1.0 -I$(HOST_DIR)/include/libusb-1.0 \
-	-fpermissive -Wno-write-strings
-
-define HOST_MFGTOOLS_CLI_BUILD
-	$(HOST_CONFIGURE_OPTS) $(MAKE) CC="$(HOSTCXX)" \
-		CFLAGS="$(HOST_MFGTOOLS_CFLAGS)" -C $(@D)/TestPrgm
-endef
-
-HOST_MFGTOOLS_POST_BUILD_HOOKS += HOST_MFGTOOLS_CLI_BUILD
-
-define HOST_MFGTOOLS_INSTALL_CMDS
-	$(INSTALL) -D -m 755 $(@D)/MfgToolLib/libMfgToolLib.so \
-		$(HOST_DIR)/lib/libMfgToolLib.so
-	$(INSTALL) -D -m 755 $(@D)/TestPrgm/mfgtoolcli \
-		$(HOST_DIR)/bin/mfgtoolcli
+# Version string generation is broken in mfgtools as it relies on git, even
+# when building from a source tarball. The version string is used by mfgtools
+# do a runtime check to detect outdated command list scripts. We overwrite
+# gen_ver.sh with something that simply prints a define for GIT_VERSION with
+# the mfgtools version (preceeded by "lib", as done in the original gen_ver.sh).
+define HOST_MFGTOOLS_OVERWRITE_GEN_VER_SH
+        echo '#!/bin/sh' > $(@D)/libuuu/gen_ver.sh
+        echo 'echo "#define GIT_VERSION \"lib$(MFGTOOLS_VERSION)\"" > $$1' >> $(@D)/libuuu/gen_ver.sh
 endef
+HOST_MFGTOOLS_POST_PATCH_HOOKS += HOST_MFGTOOLS_OVERWRITE_GEN_VER_SH
 
 $(eval $(host-cmake-package))
diff --git a/package/mfgtools/readme.txt b/package/mfgtools/readme.txt
index 320e6ec493..8a916d1cae 100644
--- a/package/mfgtools/readme.txt
+++ b/package/mfgtools/readme.txt
@@ -18,45 +18,16 @@  CONFIG_USB_MASS_STORAGE=y
 CONFIG_FSL_UTP=y
 CONFIG_MMC_BLOCK_MINORS=16
 
-2. Go into the output and create the necessary folders
+2. Run the MfgTools (now called uuu) client to boot the board from USB:
 
-$ cd output
-$ mkdir -p "Profiles/Linux/OS Firmware/firmware"
+$ ./output/host/bin/uuu output/images/u-boot.imx
 
-3. Create your XML update script named ucl2.xml
+At this point you can either flash your kernel and rootfs image directly from
+U-Boot or use commands in order to load your ramdisk and execute commands from
+Linux OS.
 
-You can find a sample XML at:
-
-$ wget https://storage.googleapis.com/boundarydevices.com/ucl2.xml \
-  -O Profiles/Linux/OS\ Firmware/ucl2.xml
-
-4. Copy the U-Boot, Kernel and initramfs images to the appropriate
-folder
-
-$ cp images/u-boot.imx images/zImage images/imx6q-sabrelite.dtb \
-  images/rootfs.cpio.uboot Profiles/Linux/OS\ Firmware/firmware/
-
-5. Copy the prebuilt binaries to be flashed
-
-Depending on your ucl2.xml file, the sample doesn't flash anything.
-
-6. Run the MfgTools client:
-
-$ ./host/bin/mfgtoolcli -l mmc -s uboot_defconfig=imx \
-  -s dtbname=imx6q-sabrelite.dtb -s initramfs=rootfs.cpio.uboot \
-  -s mmc=1 -p 1
-
-For more information about the tools options, please read the
-"Manufacturing Tool V2 Quick Start Guide.docx" documentation contained
-in every mfgtools package from NXP website[1].
-
-Note: All the above commands require your Linux host user to have
-permissions to access the USB devices. Please make sure to have udev
-rules that allow the user to communicate with the BootROM IDs
-(Freescale USB recovery) as well as the one used for the UTP Linux
-image (0x066F:0x37FF).  Using 'sudo' in front of the mfgtoolcli
-command would also grant you the necessary permission but it is *not*
-recommended.
+For more information about the tools options, please read this wiki:
+https://github.com/NXPmicro/mfgtools/wiki
 
 Also, if your U-Boot environment doesn't include mfgtools bootargs,
 make sure to set the following:
@@ -65,5 +36,3 @@  setenv bootargs "console=${console},${baudrate} g_mass_storage.stall=0 \
 	g_mass_storage.removable=1 g_mass_storage.idVendor=0x066F \
 	g_mass_storage.idProduct=0x37FF g_mass_storage.iSerialNumber=\"\" \
 	g_mass_storage.file=/fat"
-
-[1] http://www.nxp.com/products/software-and-tools/software-development-tools/i.mx-software-and-tools/i.mx-6-series-software-and-development-tool-resources:IMX6_SW