[U-Boot] [PATCH 0/5] tools: Support building U-Boot host tools for Windows via MSYS2

[U-Boot] [PATCH 0/5] tools: Support building U-Boot host tools for Windows via MSYS2

[Bin Meng]

Per current U-Boot README, building Windows versions of the utilities
in the tools directory is done via the MinGW toolchain. But testing
shows that it is broken and actually it must have been broken for
quite a long time.

Fixing MinGW build seems quite amount of work as developers of
U-Boot normally work on Linux boxes hence codes written are mainly
for Linux or POSIX OSes. We must investigate another way of building
host tools for Windows, and now we have MSYS2, a software distro and
building platform for Windows, to build POSIX compliant software on
Windows using an emulation layer.

This small series fixes several issues in current U-Boot tools codes,
that only assume a Linux host is used. Cases are using standard C
typedefs whenever possbile, or using compiler builtin functions to
improve portability, etc.

A reST document for how to build U-Boot host tools for both platforms
is added.


Bin Meng (5):
  tools: image.h: Use portable uint32_t instead of linux-specific __be32
  tools: mtk_image.h: Use portable uintXX_t instead of linux-specific
    __leXX
  tools: zynqmpbif: Use compiler builtin instead of linux-specific
    __swab32
  linux/types.h: Surround 'struct ustat' with __linux__
  doc: Add documentation for how to build U-Boot host tools

 doc/build/index.rst   |  9 ++++++
 doc/build/tools.rst   | 47 ++++++++++++++++++++++++++++
 doc/index.rst         | 11 +++++++
 include/image.h       | 14 ++++-----
 include/linux/types.h |  2 ++
 tools/mtk_image.h     | 86 +++++++++++++++++++++++++--------------------------
 tools/zynqmpbif.c     |  2 +-
 7 files changed, 120 insertions(+), 51 deletions(-)
 create mode 100644 doc/build/index.rst
 create mode 100644 doc/build/tools.rst

-- 
2.7.4

[U-Boot] [PATCH 1/5] tools: image.h: Use portable uint32_t instead of linux-specific __be32

[Bin Meng]

__be32 has Linux kernel specific __attribute__((bitwise)) which is
not portable. Use uint32_t instead.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 include/image.h | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/include/image.h b/include/image.h
index c1065c0..f4d2aaf 100644
--- a/include/image.h
+++ b/include/image.h
@@ -319,13 +319,13 @@ enum {
  * all data in network byte order (aka natural aka bigendian).
  */
 typedef struct image_header {
-	__be32		ih_magic;	/* Image Header Magic Number	*/
-	__be32		ih_hcrc;	/* Image Header CRC Checksum	*/
-	__be32		ih_time;	/* Image Creation Timestamp	*/
-	__be32		ih_size;	/* Image Data Size		*/
-	__be32		ih_load;	/* Data	 Load  Address		*/
-	__be32		ih_ep;		/* Entry Point Address		*/
-	__be32		ih_dcrc;	/* Image Data CRC Checksum	*/
+	uint32_t	ih_magic;	/* Image Header Magic Number	*/
+	uint32_t	ih_hcrc;	/* Image Header CRC Checksum	*/
+	uint32_t	ih_time;	/* Image Creation Timestamp	*/
+	uint32_t	ih_size;	/* Image Data Size		*/
+	uint32_t	ih_load;	/* Data	 Load  Address		*/
+	uint32_t	ih_ep;		/* Entry Point Address		*/
+	uint32_t	ih_dcrc;	/* Image Data CRC Checksum	*/
 	uint8_t		ih_os;		/* Operating System		*/
 	uint8_t		ih_arch;	/* CPU architecture		*/
 	uint8_t		ih_type;	/* Image Type			*/
-- 
2.7.4

[U-Boot] [PATCH 2/5] tools: mtk_image.h: Use portable uintXX_t instead of linux-specific __leXX

[Bin Meng]

__leXX has Linux kernel specific __attribute__((bitwise)) which is
not portable. Use corresponding uintXX_t instead.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 tools/mtk_image.h | 86 +++++++++++++++++++++++++++----------------------------
 1 file changed, 43 insertions(+), 43 deletions(-)

diff --git a/tools/mtk_image.h b/tools/mtk_image.h
index 0a9eab3..4e78b3d 100644
--- a/tools/mtk_image.h
+++ b/tools/mtk_image.h
@@ -9,14 +9,14 @@
 #ifndef _MTK_IMAGE_H
 #define _MTK_IMAGE_H
 
-/* Device header definitions */
+/* Device header definitions, all fields are little-endian */
 
 /* Header for NOR/SD/eMMC */
 union gen_boot_header {
 	struct {
 		char name[12];
-		__le32 version;
-		__le32 size;
+		uint32_t version;
+		uint32_t size;
 	};
 
 	uint8_t pad[0x200];
@@ -32,14 +32,14 @@ union nand_boot_header {
 		char name[12];
 		char version[4];
 		char id[8];
-		__le16 ioif;
-		__le16 pagesize;
-		__le16 addrcycles;
-		__le16 oobsize;
-		__le16 pages_of_block;
-		__le16 numblocks;
-		__le16 writesize_shift;
-		__le16 erasesize_shift;
+		uint16_t ioif;
+		uint16_t pagesize;
+		uint16_t addrcycles;
+		uint16_t oobsize;
+		uint16_t pages_of_block;
+		uint16_t numblocks;
+		uint16_t writesize_shift;
+		uint16_t erasesize_shift;
 		uint8_t dummy[60];
 		uint8_t ecc_parity[28];
 	};
@@ -54,14 +54,14 @@ union nand_boot_header {
 /* BootROM layout header */
 struct brom_layout_header {
 	char name[8];
-	__le32 version;
-	__le32 header_size;
-	__le32 total_size;
-	__le32 magic;
-	__le32 type;
-	__le32 header_size_2;
-	__le32 total_size_2;
-	__le32 unused;
+	uint32_t version;
+	uint32_t header_size;
+	uint32_t total_size;
+	uint32_t magic;
+	uint32_t type;
+	uint32_t header_size_2;
+	uint32_t total_size_2;
+	uint32_t unused;
 };
 
 #define BRLYT_NAME		"BRLYT"
@@ -90,8 +90,8 @@ struct gen_device_header {
 struct gfh_common_header {
 	uint8_t magic[3];
 	uint8_t version;
-	__le16 size;
-	__le16 type;
+	uint16_t size;
+	uint16_t type;
 };
 
 #define GFH_HEADER_MAGIC	"MMM"
@@ -106,17 +106,17 @@ struct gfh_common_header {
 struct gfh_file_info {
 	struct gfh_common_header gfh;
 	char name[12];
-	__le32 unused;
-	__le16 file_type;
+	uint32_t unused;
+	uint16_t file_type;
 	uint8_t flash_type;
 	uint8_t sig_type;
-	__le32 load_addr;
-	__le32 total_size;
-	__le32 max_size;
-	__le32 hdr_size;
-	__le32 sig_size;
-	__le32 jump_offset;
-	__le32 processed;
+	uint32_t load_addr;
+	uint32_t total_size;
+	uint32_t max_size;
+	uint32_t hdr_size;
+	uint32_t sig_size;
+	uint32_t jump_offset;
+	uint32_t processed;
 };
 
 #define GFH_FILE_INFO_NAME	"FILE_INFO"
@@ -129,16 +129,16 @@ struct gfh_file_info {
 
 struct gfh_bl_info {
 	struct gfh_common_header gfh;
-	__le32 attr;
+	uint32_t attr;
 };
 
 struct gfh_brom_cfg {
 	struct gfh_common_header gfh;
-	__le32 cfg_bits;
-	__le32 usbdl_by_auto_detect_timeout_ms;
+	uint32_t cfg_bits;
+	uint32_t usbdl_by_auto_detect_timeout_ms;
 	uint8_t unused[0x48];
-	__le32 usbdl_by_kcol0_timeout_ms;
-	__le32 usbdl_by_flag_timeout_ms;
+	uint32_t usbdl_by_kcol0_timeout_ms;
+	uint32_t usbdl_by_flag_timeout_ms;
 	uint32_t pad;
 };
 
@@ -157,15 +157,15 @@ struct gfh_anti_clone {
 	uint8_t ac_b2k;
 	uint8_t ac_b2c;
 	uint16_t pad;
-	__le32 ac_offset;
-	__le32 ac_len;
+	uint32_t ac_offset;
+	uint32_t ac_len;
 };
 
 struct gfh_brom_sec_cfg {
 	struct gfh_common_header gfh;
-	__le32 cfg_bits;
+	uint32_t cfg_bits;
 	char customer_name[0x20];
-	__le32 pad;
+	uint32_t pad;
 };
 
 #define BROM_SEC_CFG_JTAG_EN	1
@@ -184,11 +184,11 @@ struct gfh_header {
 
 union lk_hdr {
 	struct {
-		__le32 magic;
-		__le32 size;
+		uint32_t magic;
+		uint32_t size;
 		char name[32];
-		__le32 loadaddr;
-		__le32 mode;
+		uint32_t loadaddr;
+		uint32_t mode;
 	};
 
 	uint8_t data[512];
-- 
2.7.4

[U-Boot] [PATCH 3/5] tools: zynqmpbif: Use compiler builtin instead of linux-specific __swab32

[Bin Meng]

__swab32() is a Linux specific macro defined in linux/swab.h. Let's
use the compiler equivalent builtin function __builtin_bswap32() for
better portability.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 tools/zynqmpbif.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/zynqmpbif.c b/tools/zynqmpbif.c
index 8c47107..82ce0ac 100644
--- a/tools/zynqmpbif.c
+++ b/tools/zynqmpbif.c
@@ -517,7 +517,7 @@ static int bif_add_bit(struct bif_entry *bf)
 	debug("Bitstream Length: 0x%x\n", bitlen);
 	for (i = 0; i < bitlen; i += sizeof(uint32_t)) {
 		uint32_t *bitbin32 = (uint32_t *)&bitbin[i];
-		*bitbin32 = __swab32(*bitbin32);
+		*bitbin32 = __builtin_bswap32(*bitbin32);
 	}
 
 	if (!bf->dest_dev)
-- 
2.7.4

[U-Boot] [PATCH 4/5] linux/types.h: Surround 'struct ustat' with __linux__

[Bin Meng]

'struct ustat' uses linux-specific typedefs to declare its memebers:
__kernel_daddr_t and __kernel_ino_t. It is currently not used by any
U-Boot codes, but when we build U-Boot tools for other platform like
Windows, this becomes a problem.

Let's surround it with __linux__.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 include/linux/types.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/types.h b/include/linux/types.h
index cc6f7cb..51cb284 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -151,12 +151,14 @@ typedef __u32 __bitwise __wsum;
 
 typedef unsigned __bitwise__	gfp_t;
 
+#ifdef __linux__
 struct ustat {
 	__kernel_daddr_t	f_tfree;
 	__kernel_ino_t		f_tinode;
 	char			f_fname[6];
 	char			f_fpack[6];
 };
+#endif
 
 #define DECLARE_BITMAP(name, bits) \
 	unsigned long name[BITS_TO_LONGS(bits)]
-- 
2.7.4

[U-Boot] [PATCH 5/5] doc: Add documentation for how to build U-Boot host tools

[Bin Meng]

This adds a reST document for how to build U-Boot host tools,
including information for both Linux and Windows.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

---

 doc/build/index.rst |  9 +++++++++
 doc/build/tools.rst | 47 +++++++++++++++++++++++++++++++++++++++++++++++
 doc/index.rst       | 11 +++++++++++
 3 files changed, 67 insertions(+)
 create mode 100644 doc/build/index.rst
 create mode 100644 doc/build/tools.rst

diff --git a/doc/build/index.rst b/doc/build/index.rst
new file mode 100644
index 0000000..e4e3411
--- /dev/null
+++ b/doc/build/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Build U-Boot
+============
+
+.. toctree::
+   :maxdepth: 2
+
+   tools
diff --git a/doc/build/tools.rst b/doc/build/tools.rst
new file mode 100644
index 0000000..c06f915
--- /dev/null
+++ b/doc/build/tools.rst
@@ -0,0 +1,47 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. sectionauthor:: Bin Meng <bmeng.cn@gmail.com>
+
+Host tools
+==========
+
+Building tools for Linux
+------------------------
+
+To allow distributions to distribute all possible tools in a generic way,
+avoiding the need of specific tools building for each machine, a tools only
+defconfig file is provided.
+
+Using this, we can build the tools by doing::
+
+   $ make tools-only_defconfig
+   $ make tools-only
+
+Building tools for Windows
+--------------------------
+If you wish to generate Windows versions of the utilities in the tools directory
+you can use MSYS2, a software distro and building platform for Windows.
+
+Download the MSYS2 installer from https://www.msys2.org. Make sure you have
+installed all required packages below in order to build these host tools::
+
+   * gcc (9.1.0)
+   * make (4.2.1)
+   * bison (3.4.2)
+   * diffutils (3.7)
+   * openssl-devel (1.1.1.d)
+
+Note the version numbers in these parentheses above are the package versions
+at the time being when writing this document. The MSYS2 installer tested is
+http://repo.msys2.org/distrib/x86_64/msys2-x86_64-20190524.exe.
+
+There are 3 MSYS subsystems installed: MSYS2, MinGW32 and MinGW64. Each
+subsystem provides an environment to build Windows applications. The MSYS2
+environment is for building POSIX compliant software on Windows using an
+emulation layer. The MinGW32/64 subsystems are for building native Windows
+applications using a linux toolchain (gcc, bash, etc), targeting respectively
+32 and 64 bit Windows.
+
+Launch the MSYS2 shell of the MSYS2 environment, and do the following::
+
+   $ make tools-only_defconfig
+   $ make tools-only NO_SDL=1
diff --git a/doc/index.rst b/doc/index.rst
index 458f0d2..206a045 100644
--- a/doc/index.rst
+++ b/doc/index.rst
@@ -15,6 +15,17 @@ if you want to help out.
 .. toctree::
    :maxdepth: 2
 
+User-oriented documentation
+---------------------------
+
+The following manuals are written for *users* of the U-Boot - those who are
+trying to get it to work optimally on a given system.
+
+.. toctree::
+   :maxdepth: 2
+
+   build/index
+
 Unified Extensible Firmware (UEFI)
 ----------------------------------
 
-- 
2.7.4

[U-Boot] [PATCH 5/5] doc: Add documentation for how to build U-Boot host tools

[Tom Rini]

On Wed, Oct 16, 2019 at 09:27:25AM -0700, Bin Meng wrote:

> This adds a reST document for how to build U-Boot host tools,
> including information for both Linux and Windows.
> 
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

So here's where I think things get interesting.  Off the top of my head,
I think we can use the free GitLab.com-provided hosts of which there are
Windows-based ones (we would need to do some labeling of jobs so that
most things only run on our Linux hosts but one job runs on the Windows
infra).  I'm less sure we can do such a matrix with Travis.  But is
there some way we could get this Windows tool build into CI and thus
keep it from breaking in the future?  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191016/1f9d41c9/attachment.sig>

[U-Boot] [PATCH 5/5] doc: Add documentation for how to build U-Boot host tools

[Bin Meng]

Hi Tom,

On Thu, Oct 17, 2019 at 2:20 AM Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Oct 16, 2019 at 09:27:25AM -0700, Bin Meng wrote:
>
> > This adds a reST document for how to build U-Boot host tools,
> > including information for both Linux and Windows.
> >
> > Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>
> So here's where I think things get interesting.  Off the top of my head,
> I think we can use the free GitLab.com-provided hosts of which there are
> Windows-based ones (we would need to do some labeling of jobs so that
> most things only run on our Linux hosts but one job runs on the Windows
> infra).  I'm less sure we can do such a matrix with Travis.  But is
> there some way we could get this Windows tool build into CI and thus
> keep it from breaking in the future?  Thanks!

Yes, I would like to have GitLab CI to do the Windows build for us.
However I did not find the free GitLab.com-provided hosts. Any hints?

Regards,
Bin

[U-Boot] [PATCH 5/5] doc: Add documentation for how to build U-Boot host tools

[Tom Rini]

On Thu, Oct 17, 2019 at 09:50:57AM +0800, Bin Meng wrote:
> Hi Tom,
> 
> On Thu, Oct 17, 2019 at 2:20 AM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, Oct 16, 2019 at 09:27:25AM -0700, Bin Meng wrote:
> >
> > > This adds a reST document for how to build U-Boot host tools,
> > > including information for both Linux and Windows.
> > >
> > > Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> >
> > So here's where I think things get interesting.  Off the top of my head,
> > I think we can use the free GitLab.com-provided hosts of which there are
> > Windows-based ones (we would need to do some labeling of jobs so that
> > most things only run on our Linux hosts but one job runs on the Windows
> > infra).  I'm less sure we can do such a matrix with Travis.  But is
> > there some way we could get this Windows tool build into CI and thus
> > keep it from breaking in the future?  Thanks!
> 
> Yes, I would like to have GitLab CI to do the Windows build for us.
> However I did not find the free GitLab.com-provided hosts. Any hints?

Yeah, OK, I was wrong.  You have to be on gitlab.com and they don't have
Windows.  And I don't know enough Windows to figure out how to automate
going from a Microsoft-provided free VirtualBox image to having that
have GitLab Runner also installed.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191017/ba27d9aa/attachment.sig>

[U-Boot] [PATCH 5/5] doc: Add documentation for how to build U-Boot host tools

[Bin Meng]

Hi Tom,

On Thu, Oct 17, 2019 at 10:10 PM Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Oct 17, 2019 at 09:50:57AM +0800, Bin Meng wrote:
> > Hi Tom,
> >
> > On Thu, Oct 17, 2019 at 2:20 AM Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Wed, Oct 16, 2019 at 09:27:25AM -0700, Bin Meng wrote:
> > >
> > > > This adds a reST document for how to build U-Boot host tools,
> > > > including information for both Linux and Windows.
> > > >
> > > > Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> > >
> > > So here's where I think things get interesting.  Off the top of my head,
> > > I think we can use the free GitLab.com-provided hosts of which there are
> > > Windows-based ones (we would need to do some labeling of jobs so that
> > > most things only run on our Linux hosts but one job runs on the Windows
> > > infra).  I'm less sure we can do such a matrix with Travis.  But is
> > > there some way we could get this Windows tool build into CI and thus
> > > keep it from breaking in the future?  Thanks!
> >
> > Yes, I would like to have GitLab CI to do the Windows build for us.
> > However I did not find the free GitLab.com-provided hosts. Any hints?
>
> Yeah, OK, I was wrong.  You have to be on gitlab.com and they don't have
> Windows.  And I don't know enough Windows to figure out how to automate
> going from a Microsoft-provided free VirtualBox image to having that
> have GitLab Runner also installed.

Ah that's bad we can't find a GitLab hosted free Windows VM.

So I looked at Microsoft Azure pipeline and it looks we can set up a
free account for U-Boot.
See https://azure.microsoft.com/en-us/blog/announcing-azure-pipelines-with-unlimited-ci-cd-minutes-for-open-source/

Regards,
Bin

[U-Boot] [PATCH 5/5] doc: Add documentation for how to build U-Boot host tools

[Tom Rini]

On Thu, Oct 17, 2019 at 11:02:47PM +0800, Bin Meng wrote:
> Hi Tom,
> 
> On Thu, Oct 17, 2019 at 10:10 PM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Oct 17, 2019 at 09:50:57AM +0800, Bin Meng wrote:
> > > Hi Tom,
> > >
> > > On Thu, Oct 17, 2019 at 2:20 AM Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Wed, Oct 16, 2019 at 09:27:25AM -0700, Bin Meng wrote:
> > > >
> > > > > This adds a reST document for how to build U-Boot host tools,
> > > > > including information for both Linux and Windows.
> > > > >
> > > > > Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> > > >
> > > > So here's where I think things get interesting.  Off the top of my head,
> > > > I think we can use the free GitLab.com-provided hosts of which there are
> > > > Windows-based ones (we would need to do some labeling of jobs so that
> > > > most things only run on our Linux hosts but one job runs on the Windows
> > > > infra).  I'm less sure we can do such a matrix with Travis.  But is
> > > > there some way we could get this Windows tool build into CI and thus
> > > > keep it from breaking in the future?  Thanks!
> > >
> > > Yes, I would like to have GitLab CI to do the Windows build for us.
> > > However I did not find the free GitLab.com-provided hosts. Any hints?
> >
> > Yeah, OK, I was wrong.  You have to be on gitlab.com and they don't have
> > Windows.  And I don't know enough Windows to figure out how to automate
> > going from a Microsoft-provided free VirtualBox image to having that
> > have GitLab Runner also installed.
> 
> Ah that's bad we can't find a GitLab hosted free Windows VM.
> 
> So I looked at Microsoft Azure pipeline and it looks we can set up a
> free account for U-Boot.
> See https://azure.microsoft.com/en-us/blog/announcing-azure-pipelines-with-unlimited-ci-cd-minutes-for-open-source/

That's interesting.  Would you mind trying to get something going with
that?  Maybe long term we can use that as an alternative to travis too.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191017/67c86ab4/attachment.sig>

[U-Boot] [PATCH 5/5] doc: Add documentation for how to build U-Boot host tools

[Bin Meng]

Hi Tom,

On Thu, Oct 17, 2019 at 11:12 PM Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Oct 17, 2019 at 11:02:47PM +0800, Bin Meng wrote:
> > Hi Tom,
> >
> > On Thu, Oct 17, 2019 at 10:10 PM Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Oct 17, 2019 at 09:50:57AM +0800, Bin Meng wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, Oct 17, 2019 at 2:20 AM Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Wed, Oct 16, 2019 at 09:27:25AM -0700, Bin Meng wrote:
> > > > >
> > > > > > This adds a reST document for how to build U-Boot host tools,
> > > > > > including information for both Linux and Windows.
> > > > > >
> > > > > > Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> > > > >
> > > > > So here's where I think things get interesting.  Off the top of my head,
> > > > > I think we can use the free GitLab.com-provided hosts of which there are
> > > > > Windows-based ones (we would need to do some labeling of jobs so that
> > > > > most things only run on our Linux hosts but one job runs on the Windows
> > > > > infra).  I'm less sure we can do such a matrix with Travis.  But is
> > > > > there some way we could get this Windows tool build into CI and thus
> > > > > keep it from breaking in the future?  Thanks!
> > > >
> > > > Yes, I would like to have GitLab CI to do the Windows build for us.
> > > > However I did not find the free GitLab.com-provided hosts. Any hints?
> > >
> > > Yeah, OK, I was wrong.  You have to be on gitlab.com and they don't have
> > > Windows.  And I don't know enough Windows to figure out how to automate
> > > going from a Microsoft-provided free VirtualBox image to having that
> > > have GitLab Runner also installed.
> >
> > Ah that's bad we can't find a GitLab hosted free Windows VM.
> >
> > So I looked at Microsoft Azure pipeline and it looks we can set up a
> > free account for U-Boot.
> > See https://azure.microsoft.com/en-us/blog/announcing-azure-pipelines-with-unlimited-ci-cd-minutes-for-open-source/
>
> That's interesting.  Would you mind trying to get something going with
> that?  Maybe long term we can use that as an alternative to travis too.

Sure, I will give a try.

Regards,
Bin