[PATCH v4 08/11] tools: binman: Add a test for boot and load extensions

[Simon Glass]

Hi Beleswar,

On 2026-04-25T03:37:39, Padhi, Beleswar <b-padhi at ti.com> wrote:
> tools: binman: Add a test for boot and load extensions
>
> Add test coverage for the boot and load extension functionality in
> ti-secure certificates. This verifies that a certificate can be
> generated having boot and load extensions.
>
> Signed-off-by: Beleswar Padhi <b-padhi at ti.com>
>
> tools/binman/ftest.py                              | 10 ++++++++++
>  .../binman/test/vendor/ti_secure_boot_load_ext.dts | 23 ++++++++++++++++++++++
>  2 files changed, 33 insertions(+)

> diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
> @@ -7270,6 +7270,16 @@ fdt         fdtmap                Extract the devicetree blob from the fdtmap
> +    def testPackTiSecureBootLoadExt(self):
> +        """Test that an image with TI secured binary having boot & load extensions can be created"""
> +        keyfile = self.TestFile('security/key.key')
> +        entry_args = {
> +            'keyfile': keyfile,
> +        }
> +        data = self._DoReadFileDtb('vendor/ti_secure_boot_load_ext.dts',
> +                                   entry_args=entry_args)[0]
> +        self.assertGreater(len(data), len(TI_UNSECURE_DATA))

This only asserts that the resulting blob is larger than the unsecured
input, which is true for any signed output and tells us nothing about
the new code paths in patch 7. Please verify the actual behaviour -
e.g. read back the generated config.* file (or parse the cert) and
check that the sysfw_boot_seq and sysfw_image_load sections contain
the expected bootCore, resetVec, destAddr and authInPlace values from
the DTS. Otherwise this would happily pass even if
ReadLoadableCoreNode() returned None for both extensions.

> diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
> @@ -7270,6 +7270,16 @@ fdt         fdtmap                Extract the devicetree blob from the fdtmap
> +    def testPackTiSecureBootLoadExt(self):

Since ReadDictFromList() in patch 7 returns None as soon as any single
property is missing, please add at least one negative case, like a DTS
with proc_id only, to confirm that boot_ext ends up None and the
certificate falls back to the firewall authInPlace branch. As it
stands, only the all-properties-present path is exercised here.

Reviewed-by: Simon Glass <sjg at chromium.org>

Regards,
Simon