Hi Quentin,
Am 01.09.2022 um 16:34 schrieb Quentin Schulz:
Hi Stefan,
On 9/1/22 08:12, Stefan Herbrechtsmeier wrote:
Hi Quentin,
Am 31.08.2022 um 19:44 schrieb Simon Glass:
On Wed, 31 Aug 2022 at 09:55, Quentin Schulz foss+uboot@0leil.net wrote:
From: Quentin Schulz quentin.schulz@theobroma-systems.com
The binary is looked on the system by the suffix of the packer class. This means binman was looking for btool_gzip on the system and not gzip.
Are you sure? I test it and the name is already gzip because the bintool is requested as gzip. The find_bintool_class function only change the class name.
From current master: tools/binman/binman tool --list Name Version Description Path
--------------- ----------- -------------------------
btool_gzip - btool_gzip compression (not found)
With my patch: tools/binman/binman tool --list Name Version Description Path
--------------- ----------- -------------------------
gzip 1.11 gzip compression /usr/bin/gzip
Bintool.get_tool_list will return btool_gzip. Bintool.list_all will then iterate over all tools and call Bintool.create(name) for each.
Bintool.create will call Bintool.find_bintool_class with btool_gzip and it'll return the Bintoolbtool_gzip class. Then its constructor will be called, with btool_gzip passed as argument, here: https://source.denx.de/u-boot/u-boot/-/blob/master/tools/binman/bintool.py#L...
Ok, we use different ways to test it. I use the version test and this use a fixed gzip name as input.
This is because Bintool.create has no knowledge of btool_gzip actually being gzip unlike Bintool.find_bintool_class.
Another way to handle this, and without user intervention would be to remove btool_ prefix when listing the supported tools since Bintool.find_bintool_class will actually handle the case where the prefix is missing.
I think this is a better solution.
It'd be something like:
Applied to u-boot-dm, thanks!