<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/tools, branch v2025.04</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.</subtitle>
<id>http://cgit.235523.xyz/u-boot.git/atom/tools?h=v2025.04</id>
<link rel='self' href='http://cgit.235523.xyz/u-boot.git/atom/tools?h=v2025.04'/>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<updated>2025-04-07T13:34:49Z</updated>
<entry>
<title>buildman: update PyYAML requirement</title>
<updated>2025-04-07T13:34:49Z</updated>
<author>
<name>Heinrich Schuchardt</name>
<email>heinrich.schuchardt@canonical.com</email>
</author>
<published>2025-04-07T06:47:12Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=38b34711152937b124ba91f0519813c161d9d60f'/>
<id>urn:sha1:38b34711152937b124ba91f0519813c161d9d60f</id>
<content type='text'>
On Ubuntu 25.04 installing the dependency pyyaml 6.0 fails with

    License classifiers are deprecated

Update PyYAML to the current release.

Signed-off-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</content>
</entry>
<entry>
<title>dumpimage: fix handling of StarFive SPL too long</title>
<updated>2025-03-18T14:17:32Z</updated>
<author>
<name>Heinrich Schuchardt</name>
<email>heinrich.schuchardt@canonical.com</email>
</author>
<published>2025-03-04T16:04:03Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=15ba2b7356af035bc7dfd5c279e9658291fc7cf3'/>
<id>urn:sha1:15ba2b7356af035bc7dfd5c279e9658291fc7cf3</id>
<content type='text'>
The header of the StarFive U-Boot SPL file u-boot-spl.normal.out has a
field indicating the payload size. When copying U-Boot SPL from a
partition the copied file might be too long.

Currently in this situation a misleading error message 'Incorrect CRC32' is
written.

We must use the payload size and not the file size when calculating the
CRC32.

Write a warning if the file is too long indicating the correct size. This
enables the user to truncate the file accordingly.

Signed-off-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</content>
</entry>
<entry>
<title>qconfig: Correct unhashable-type error with --scan-source</title>
<updated>2025-03-18T14:17:30Z</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2025-02-27T19:27:19Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=301c2ab729447b0f7c602e054c3f22a5a9df1b24'/>
<id>urn:sha1:301c2ab729447b0f7c602e054c3f22a5a9df1b24</id>
<content type='text'>
This gives an error with newer Python version, so fix it.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
</entry>
<entry>
<title>binman: Honour the skip-at-start property more faithfully</title>
<updated>2025-03-04T14:22:11Z</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2025-02-26T16:26:17Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=2c252d36b8da37e5601af5421bc672474b849e97'/>
<id>urn:sha1:2c252d36b8da37e5601af5421bc672474b849e97</id>
<content type='text'>
A discussion on the mailing list about dealing with block offsets and
binman symbols made me think that something is wrong with how Binman
deals with the skip-at-start property.

The feature was originally designed to handle x86 ROMs, which are mapped
at the top of the address space. That seemed too specific, whereas
skipping some space at the start seemed more generally useful.

It has proved useful. For example, rockchip images start at block 64,
so a skip-at-start of 0x8000 deals with this.

But it doesn't actually work correctly, since the image_pos value does
not give the actual position on the media.

Fix this and update the documentation, moving it into the 'section'
section.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
</entry>
<entry>
<title>binman: Rename Entry.end_4gb</title>
<updated>2025-03-04T14:22:10Z</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2025-02-26T16:26:16Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=91fa9d9ed2e10d6f96a80b9655c105fe99592519'/>
<id>urn:sha1:91fa9d9ed2e10d6f96a80b9655c105fe99592519</id>
<content type='text'>
The property is named end_at_4gb so name the variable the same, to avoid
confusion.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
</entry>
<entry>
<title>tools: use cryptographically safe RNG</title>
<updated>2025-02-18T18:30:32Z</updated>
<author>
<name>Heinrich Schuchardt</name>
<email>heinrich.schuchardt@canonical.com</email>
</author>
<published>2025-02-11T13:55:22Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=50e8089c1de107137c7a30fd5691ebd449f42e2d'/>
<id>urn:sha1:50e8089c1de107137c7a30fd5691ebd449f42e2d</id>
<content type='text'>
The PRNG implementing the random() function only has 2^31 states and
therefore is unsafe to use for cryptography. Use arc4random() instead.

Fixes: cc34f04efd63 ("tools: image-host.c: use random instead of rand")
Addresses-Coverity-ID: 312953 Calling risky function
Signed-off-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</content>
</entry>
<entry>
<title>tools: mkenvimage: List -V parameter in help text</title>
<updated>2025-02-10T16:27:01Z</updated>
<author>
<name>Marek Vasut</name>
<email>marex@denx.de</email>
</author>
<published>2025-02-05T14:34:28Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=7764d7d65383ca3557e0c1cff40bbb716bbb79e1'/>
<id>urn:sha1:7764d7d65383ca3557e0c1cff40bbb716bbb79e1</id>
<content type='text'>
The -V version parameter is missing in the optional list of parameters
in help text. Add it.

Signed-off-by: Marek Vasut &lt;marex@denx.de&gt;
</content>
</entry>
<entry>
<title>lib: Allow crc16 code to be dropped</title>
<updated>2025-02-03T22:00:42Z</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2025-01-26T18:43:14Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=5929c2f39f557940a49d2852f95ade939358b705'/>
<id>urn:sha1:5929c2f39f557940a49d2852f95ade939358b705</id>
<content type='text'>
This code is not necessarily needed in VPL, even if SPL uses it, so
adjust the rules to allow it to be dropped.

Do the same for the hash API.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Reviewed-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
</entry>
<entry>
<title>tools: check result of lseek</title>
<updated>2025-01-26T17:35:46Z</updated>
<author>
<name>Maks Mishin</name>
<email>maks.mishinfz@gmail.com</email>
</author>
<published>2025-01-22T16:15:04Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=f55fa90a959e4644b89c56e692930810c5c462b4'/>
<id>urn:sha1:f55fa90a959e4644b89c56e692930810c5c462b4</id>
<content type='text'>
Return value of function 'lseek', called at pblimage.c:211,
is not checked, but it is usually checked for this function.

This trigger was found using the Svace static analyzer.

Signed-off-by: Maks Mishin &lt;maks.mishinFZ@gmail.com&gt;
Reviewed-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
</entry>
<entry>
<title>buildman: Record an error if a toolchain is missing</title>
<updated>2025-01-25T22:27:24Z</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2024-12-14T18:20:23Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=bd7883f3467645359f72647f78abffbdd5a236fa'/>
<id>urn:sha1:bd7883f3467645359f72647f78abffbdd5a236fa</id>
<content type='text'>
Buildman has always treated the lack of a toolchain as an infrastructure
problem rather than a build failure.

However the logic for this is not correct, since it does not write a
'done' file in this case.

As a result, one of two things can happen.

1. If a previous build ran in the same (output) directory, the outcome
   of *that* build is recorded as the outcome of this one
2. Otherwise, no outcome is recorded

Obviously this inconsistency is not ideal. While (2) is rare, it can be
very confusing as the build sort-of fails but does not produce any
summary output with 'buildman -s'

Overall it seems better to attribute a toolchain issue to the boards
that it affects. This results in clear failures which can be examined,
no matter what happened in the .bm-work directory previously.

So write a 'done' file for each build when a toolchain is missing.

The end result of this patch is to make missing toolchains much more
obvious. It should be things a bit easier for novice users.

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