<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/tools, branch v2019.01-rc2</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<entry>
<title>tools: mtk_image: replace strncpy(d, s, sizeof(d)) with snprintf()</title>
<updated>2018-12-15T16:49:56+00:00</updated>
<author>
<name>Andy Shevchenko</name>
<email>andriy.shevchenko@linux.intel.com</email>
</author>
<published>2018-12-11T14:41:43+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=74473ed0cf171acaf370b6ab2123b763107d5121'/>
<id>74473ed0cf171acaf370b6ab2123b763107d5121</id>
<content type='text'>
Starting from version 8 the GCC, i.e. C compiler, starts complaining about
possible '\0' terminator loss or, as in this case, garbage copy.

In function ‘mtk_image_set_gen_header’,
    inlined from ‘mtk_image_set_header’ at tools/mtk_image.c:733:3:
tools/mtk_image.c:659:2: warning: ‘strncpy’ specified bound 12 equals destination size [-Wstringop-truncation]
  strncpy(hdr-&gt;boot.name, bootname, sizeof(hdr-&gt;boot.name));
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function ‘mtk_brom_parse_imagename’,
    inlined from ‘mtk_image_check_params’ at tools/mtk_image.c:388:9:
tools/mtk_image.c:325:5: warning: ‘strncpy’ specified bound 32 equals destination size [-Wstringop-truncation]
     strncpy(lk_name, val, sizeof(lk_name));
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Replace it with snprintf() to tell compiler how much room we have in the
destination buffer for source string.

Fixes: 3b975a147c3c ("tools: MediaTek: add MTK boot header generation to mkimage")
Cc: Ryder Lee &lt;ryder.lee@mediatek.com&gt;
Cc: Weijie Gao &lt;weijie.gao@mediatek.com&gt;
Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Reviewed-by: Weijie Gao &lt;weijie.gao@mediatek.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Starting from version 8 the GCC, i.e. C compiler, starts complaining about
possible '\0' terminator loss or, as in this case, garbage copy.

In function ‘mtk_image_set_gen_header’,
    inlined from ‘mtk_image_set_header’ at tools/mtk_image.c:733:3:
tools/mtk_image.c:659:2: warning: ‘strncpy’ specified bound 12 equals destination size [-Wstringop-truncation]
  strncpy(hdr-&gt;boot.name, bootname, sizeof(hdr-&gt;boot.name));
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function ‘mtk_brom_parse_imagename’,
    inlined from ‘mtk_image_check_params’ at tools/mtk_image.c:388:9:
tools/mtk_image.c:325:5: warning: ‘strncpy’ specified bound 32 equals destination size [-Wstringop-truncation]
     strncpy(lk_name, val, sizeof(lk_name));
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Replace it with snprintf() to tell compiler how much room we have in the
destination buffer for source string.

Fixes: 3b975a147c3c ("tools: MediaTek: add MTK boot header generation to mkimage")
Cc: Ryder Lee &lt;ryder.lee@mediatek.com&gt;
Cc: Weijie Gao &lt;weijie.gao@mediatek.com&gt;
Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Reviewed-by: Weijie Gao &lt;weijie.gao@mediatek.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tools: add a generic config for native tools building</title>
<updated>2018-12-15T16:49:56+00:00</updated>
<author>
<name>Otavio Salvador</name>
<email>otavio@ossystems.com.br</email>
</author>
<published>2018-12-08T00:00:41+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=80870e2a664e277df0b6c0604bc4c5591aebde67'/>
<id>80870e2a664e277df0b6c0604bc4c5591aebde67</id>
<content type='text'>
The motivation for this is to allow distributions to distribute all
possible tools in a generic way, avoiding the need of specific tools
building for each machine.

Especially on OpenEmbedded / Yocto Project ecosystem, it is very
common each BSP to end providing their specific tools when they need
to generate images for some SoC (e.g MX23 / MX28 in meta-freescale
case).

Using this, we can package the tools doing:

$: make tools-only_defconfig
$: make tools-only

Signed-off-by: Otavio Salvador &lt;otavio@ossystems.com.br&gt;
[trini: Add MAINTAINERS entry for myself, add to .travis.yml, make
U-Boot itself buildable to not trip up other frameworks]
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The motivation for this is to allow distributions to distribute all
possible tools in a generic way, avoiding the need of specific tools
building for each machine.

Especially on OpenEmbedded / Yocto Project ecosystem, it is very
common each BSP to end providing their specific tools when they need
to generate images for some SoC (e.g MX23 / MX28 in meta-freescale
case).

Using this, we can package the tools doing:

$: make tools-only_defconfig
$: make tools-only

Signed-off-by: Otavio Salvador &lt;otavio@ossystems.com.br&gt;
[trini: Add MAINTAINERS entry for myself, add to .travis.yml, make
U-Boot itself buildable to not trip up other frameworks]
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Roll CRC16-CCITT into the hash infrastructure</title>
<updated>2018-12-09T01:18:44+00:00</updated>
<author>
<name>Philipp Tomsich</name>
<email>philipp.tomsich@theobroma-systems.com</email>
</author>
<published>2018-11-25T18:22:19+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=51c2345bd24837f9f67f16268da6dc71573f1325'/>
<id>51c2345bd24837f9f67f16268da6dc71573f1325</id>
<content type='text'>
The CRC16-CCITT checksum function is useful for space-constrained
applications (such as obtaining a checksum across a 2KBit or 4KBit
EEPROM) in boot applications. It has not been accessible from boot
scripts until now (due to not having a dedicated command and not being
supported by the hash infrstructure) limiting its applicability
outside of custom commands.

This adds the CRC16-CCITT (poly 0x1021, init 0x0) algorithm to the
list of available hashes and adds a new crc16_ccitt_wd_buf() to make
this possible.

Signed-off-by: Philipp Tomsich &lt;philipp.tomsich@theobroma-systems.com&gt;
[trini: Fix building crc16.o for SPL/TPL]
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The CRC16-CCITT checksum function is useful for space-constrained
applications (such as obtaining a checksum across a 2KBit or 4KBit
EEPROM) in boot applications. It has not been accessible from boot
scripts until now (due to not having a dedicated command and not being
supported by the hash infrstructure) limiting its applicability
outside of custom commands.

This adds the CRC16-CCITT (poly 0x1021, init 0x0) algorithm to the
list of available hashes and adds a new crc16_ccitt_wd_buf() to make
this possible.

Signed-off-by: Philipp Tomsich &lt;philipp.tomsich@theobroma-systems.com&gt;
[trini: Fix building crc16.o for SPL/TPL]
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>buildman/toolchain.py: handle inconsistent tarball names</title>
<updated>2018-12-05T13:06:30+00:00</updated>
<author>
<name>Trevor Woerner</name>
<email>trevor@toganlabs.com</email>
</author>
<published>2018-11-21T08:31:13+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=b11f12642f4da249d5f07bb45ba5ba9b01235818'/>
<id>b11f12642f4da249d5f07bb45ba5ba9b01235818</id>
<content type='text'>
Unfortunately, for some releases the kernel.org toolchain tarball names adhere
to the following pattern:

	&lt;hostarch&gt;-gcc-&lt;ver&gt;-nolib-&lt;targetarch&gt;-&lt;type&gt;.tar.xz

e.g.:
	x86_64-gcc-8.1.0-nolibc-aarch64-linux.tar.xz

while others use the following pattern:

	&lt;hostarch&gt;-gcc-&lt;ver&gt;-nolib_&lt;targetarch&gt;-&lt;type&gt;.tar.xz

e.g.:

	x86_64-gcc-7.3.0-nolibc_aarch64-linux.tar.xz

Notice that the first pattern has dashes throughout, while the second has
dashes throughout except just before the target architecture which has an
underscore.

The "dash throughout" versions from kernel.org are:

	8.1.0, 6.4.0, 5.5.0, 4.9.4, 4.8.5, 4.6.1

while the "dash and underscore" versions from kernel.org are:

	7.3.0, 4.9.0, 4.8.0, 4.7.3, 4.6.3, 4.6.2, 4.5.1, 4.2.4

This tweak allows the code to handle both versions. Note that this tweak also
causes the architecture parsing to get confused and find the following two
bogus architectures, "2.0" and "64", which are explicitly checked for, and
removed.

Signed-off-by: Trevor Woerner &lt;trevor@toganlabs.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Change single quotes to double quotes:
Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Unfortunately, for some releases the kernel.org toolchain tarball names adhere
to the following pattern:

	&lt;hostarch&gt;-gcc-&lt;ver&gt;-nolib-&lt;targetarch&gt;-&lt;type&gt;.tar.xz

e.g.:
	x86_64-gcc-8.1.0-nolibc-aarch64-linux.tar.xz

while others use the following pattern:

	&lt;hostarch&gt;-gcc-&lt;ver&gt;-nolib_&lt;targetarch&gt;-&lt;type&gt;.tar.xz

e.g.:

	x86_64-gcc-7.3.0-nolibc_aarch64-linux.tar.xz

Notice that the first pattern has dashes throughout, while the second has
dashes throughout except just before the target architecture which has an
underscore.

The "dash throughout" versions from kernel.org are:

	8.1.0, 6.4.0, 5.5.0, 4.9.4, 4.8.5, 4.6.1

while the "dash and underscore" versions from kernel.org are:

	7.3.0, 4.9.0, 4.8.0, 4.7.3, 4.6.3, 4.6.2, 4.5.1, 4.2.4

This tweak allows the code to handle both versions. Note that this tweak also
causes the architecture parsing to get confused and find the following two
bogus architectures, "2.0" and "64", which are explicitly checked for, and
removed.

Signed-off-by: Trevor Woerner &lt;trevor@toganlabs.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Change single quotes to double quotes:
Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>buildman/toolchain.py: fix toolchain directory</title>
<updated>2018-12-05T13:01:35+00:00</updated>
<author>
<name>Trevor Woerner</name>
<email>trevor@toganlabs.com</email>
</author>
<published>2018-11-21T08:31:12+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=d82f539ab900c52a669a4f8407a39b8fb125f0ab'/>
<id>d82f539ab900c52a669a4f8407a39b8fb125f0ab</id>
<content type='text'>
The hexagon toolchain (4.6.1) from kernel.org, for example, was packaged in
a way that is different from most toolchains. The first entry when unpacking
most toolchain tarballs is:

	gcc-&lt;version&gt;-nolib/&lt;targetarch&gt;-&lt;system&gt;

e.g.:

	gcc-8.1.0-nolibc/aarch64-linux/

The first entry of the hexagon toolchain, however, is:

	gcc-4.6.1-nolibc/

This causes the buildman logic in toolchain.py::ScanPath() to not be able to
find the "*gcc" executable since it looks in gcc-4.6.1-nolib/{.|bin|usr/bin}
instead of gcc-4.6.1/hexagon-linux/{.|bin|usr/bin}. Therefore when buildman
tries to download a set of toolchains that includes hexagon, the script fails.

This update takes the second line of the tarball unpacking (which works for
all the toolchains I've tested from kernel.org) and parses it to take the
first two elements, separated by '/'. It makes this logic a bit more robust.

Signed-off-by: Trevor Woerner &lt;trevor@toganlabs.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The hexagon toolchain (4.6.1) from kernel.org, for example, was packaged in
a way that is different from most toolchains. The first entry when unpacking
most toolchain tarballs is:

	gcc-&lt;version&gt;-nolib/&lt;targetarch&gt;-&lt;system&gt;

e.g.:

	gcc-8.1.0-nolibc/aarch64-linux/

The first entry of the hexagon toolchain, however, is:

	gcc-4.6.1-nolibc/

This causes the buildman logic in toolchain.py::ScanPath() to not be able to
find the "*gcc" executable since it looks in gcc-4.6.1-nolib/{.|bin|usr/bin}
instead of gcc-4.6.1/hexagon-linux/{.|bin|usr/bin}. Therefore when buildman
tries to download a set of toolchains that includes hexagon, the script fails.

This update takes the second line of the tarball unpacking (which works for
all the toolchains I've tested from kernel.org) and parses it to take the
first two elements, separated by '/'. It makes this logic a bit more robust.

Signed-off-by: Trevor Woerner &lt;trevor@toganlabs.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rsa: add a structure for the padding</title>
<updated>2018-12-03T15:44:10+00:00</updated>
<author>
<name>Philippe Reynes</name>
<email>philippe.reynes@softathome.com</email>
</author>
<published>2018-11-14T12:51:00+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=20031567e12bb312bff95b70767f6275e20f0346'/>
<id>20031567e12bb312bff95b70767f6275e20f0346</id>
<content type='text'>
The rsa signature use a padding algorithm. By default, we use the
padding pkcs-1.5. In order to add some new padding algorithm, we
add a padding framework to manage several padding algorithm.
The choice of the padding is done in the file .its.

Signed-off-by: Philippe Reynes &lt;philippe.reynes@softathome.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The rsa signature use a padding algorithm. By default, we use the
padding pkcs-1.5. In order to add some new padding algorithm, we
add a padding framework to manage several padding algorithm.
The choice of the padding is done in the file .its.

Signed-off-by: Philippe Reynes &lt;philippe.reynes@softathome.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tools: MediaTek: add MTK boot header generation to mkimage</title>
<updated>2018-11-29T04:04:43+00:00</updated>
<author>
<name>Ryder Lee</name>
<email>ryder.lee@mediatek.com</email>
</author>
<published>2018-11-15T02:07:49+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=3b975a147c3c028b95312824189d7489eea54984'/>
<id>3b975a147c3c028b95312824189d7489eea54984</id>
<content type='text'>
This patch adds support for MTK boot image generation.

Signed-off-by: Weijie Gao &lt;weijie.gao@mediatek.com&gt;
Signed-off-by: Ryder Lee &lt;ryder.lee@mediatek.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch adds support for MTK boot image generation.

Signed-off-by: Weijie Gao &lt;weijie.gao@mediatek.com&gt;
Signed-off-by: Ryder Lee &lt;ryder.lee@mediatek.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tools/file2include: don't use malloc.h for malloc</title>
<updated>2018-11-27T03:52:12+00:00</updated>
<author>
<name>Jonathan Gray</name>
<email>jsg@jsg.id.au</email>
</author>
<published>2018-11-18T02:03:39+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=958d46b53f3e3683a3d227a20c1935cbe88a8d65'/>
<id>958d46b53f3e3683a3d227a20c1935cbe88a8d65</id>
<content type='text'>
stdlib.h is the header for malloc since at least c89/c90.
Previously this would fail to build on OpenBSD and fallback to the wrong
header:

In file included from u-boot/tools/file2include.c:21:
u-boot/include/malloc.h:875:5: error: function-like macro
      'CONFIG_IS_ENABLED' is not defined

Signed-off-by: Jonathan Gray &lt;jsg@jsg.id.au&gt;
Reviewed-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
stdlib.h is the header for malloc since at least c89/c90.
Previously this would fail to build on OpenBSD and fallback to the wrong
header:

In file included from u-boot/tools/file2include.c:21:
u-boot/include/malloc.h:875:5: error: function-like macro
      'CONFIG_IS_ENABLED' is not defined

Signed-off-by: Jonathan Gray &lt;jsg@jsg.id.au&gt;
Reviewed-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tools: .gitignore: add prelink-riscv</title>
<updated>2018-11-26T05:57:28+00:00</updated>
<author>
<name>Lukas Auer</name>
<email>lukas.auer@aisec.fraunhofer.de</email>
</author>
<published>2018-11-22T10:26:10+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=07c098b7d61ee37d700f5e4bc4ea7ff30c0d8f32'/>
<id>07c098b7d61ee37d700f5e4bc4ea7ff30c0d8f32</id>
<content type='text'>
Ignore tools/prelink-riscv.

Signed-off-by: Lukas Auer &lt;lukas.auer@aisec.fraunhofer.de&gt;
Reviewed-by: Bin Meng &lt;bmeng.cn@gmail.com&gt;
Reviewed-by: Rick Chen &lt;rick@andestech.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Ignore tools/prelink-riscv.

Signed-off-by: Lukas Auer &lt;lukas.auer@aisec.fraunhofer.de&gt;
Reviewed-by: Bin Meng &lt;bmeng.cn@gmail.com&gt;
Reviewed-by: Rick Chen &lt;rick@andestech.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>binman: Set the pathname correctly for ELF files</title>
<updated>2018-11-21T02:14:22+00:00</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2018-11-06T22:21:33+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=4b6dbaa3073adb24f8c67f89d0f70dbcf00808b9'/>
<id>4b6dbaa3073adb24f8c67f89d0f70dbcf00808b9</id>
<content type='text'>
At present, stripped files don't have the right pathname which means that
blob compression cannot be used. Fix this.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
At present, stripped files don't have the right pathname which means that
blob compression cannot be used. Fix this.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
