From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 10CF0C433F5 for ; Sun, 6 Mar 2022 03:09:48 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 6320383BE2; Sun, 6 Mar 2022 04:08:54 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=chromium.org header.i=@chromium.org header.b="CSsIFbk/"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id AED2F83BF4; Sun, 6 Mar 2022 04:08:37 +0100 (CET) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 09B3683C27 for ; Sun, 6 Mar 2022 04:08:28 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com Received: by mail-ot1-x32a.google.com with SMTP id x8-20020a9d6288000000b005b22c373759so415941otk.8 for ; Sat, 05 Mar 2022 19:08:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=quOoHSqijBCwRVkm/CJAu76OAM/3+UPjODQSj1fgyaE=; b=CSsIFbk/KoZievijHmT78ahnnEuVf91xL9VLB42AhmyADJ+e6zy2W11IPPDUWRJdFh a3i1I+ZlQvm5PQxtnRlYbVzBqGRQGPWu+mbixu+Zl41aiBEapG1tha75vsomVa604333 vP8tVsuUCtrvQDNK36sNLLO/Y8mTJD1iGQ3lI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=quOoHSqijBCwRVkm/CJAu76OAM/3+UPjODQSj1fgyaE=; b=yPa3LDyFyKX6vKq03VVAjOoT7ht9x/ASBR0mzCHtqtrW8cvtcCc9zS4DKPP9f90AMb indLOMvAA2ehsSRKca7fCI3a/FdK7y4D58tTP6c0g2LjRUxnqGtBw1gtZUZALcnqIk3d D2adBDxCz2GoSUC2WxcIW8mSEVPEV6uQgwFCMDZPb2+aw9FYW9Bl+TYec4Tlcz90jTuE hi6h8BGUs2OoXv0KHoUXPXaPSw+0LATdfWERzq9o7NHxvITf3Ilm6ofS6UzgX0d8lPHO Bie+btfcT96Gwl4IYWi88wbuw3QeUheUzwsi1KdzatkfPe23RhqTlk/0WoNL1m842Ans zBuA== X-Gm-Message-State: AOAM532CJFKAw73Q30Z3zrtnYHMCj9Z4Pq0JCp9i+D4AHtgfcUO2tQTK hpgt/2yXHYImpYk2KzlBrgXQ6BvromksoNvYb/XNsw== X-Google-Smtp-Source: ABdhPJwsuO7MwFoSUjiiR/+oRR4Wd4MqtWMXHunZo6yfjt3oVSwHSr0qTUUhK+8k7CsqHJQBr1zxGsHtHOVO7OU2tkQ= X-Received: by 2002:a05:6830:2257:b0:59e:9b2c:4414 with SMTP id t23-20020a056830225700b0059e9b2c4414mr2669224otd.351.1646536106418; Sat, 05 Mar 2022 19:08:26 -0800 (PST) MIME-Version: 1.0 References: <20220223230040.159317-1-sjg@chromium.org> <20220223230040.159317-21-sjg@chromium.org> In-Reply-To: From: Simon Glass Date: Sat, 5 Mar 2022 20:08:14 -0700 Message-ID: Subject: Re: [PATCH v2 20/25] binman: Support splitting an ELF file into multiple nodes To: Alper Nebi Yasak Cc: Ivan Mikhaylov , Tom Rini , Philippe Reynes , huang lin , Jeffy Chen , Kever Yang , U-Boot Mailing List Content-Type: text/plain; charset="UTF-8" X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.5 at phobos.denx.de X-Virus-Status: Clean Hi Alper, On Thu, 3 Mar 2022 at 14:17, Alper Nebi Yasak wrote: > > On 24/02/2022 02:00, Simon Glass wrote: > > Some boards need to load an ELF file using the 'loadables' property, but > > the file has segments at different memory addresses. This means that it > > cannot be supplied as a flat binary. > > > > Allow generating a separate node in the FIT for each segment in the ELF, > > with a different load address for each. > > > > Also add checks that the fit,xxx directives are valid. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v2: > > - Rewrite this to use the new FIT entry-type implementation > > - Rename op-tee to tee-os > > > > tools/binman/entries.rst | 146 ++++++++++++ > > tools/binman/etype/fit.py | 230 ++++++++++++++++++- > > tools/binman/ftest.py | 147 ++++++++++++ > > tools/binman/test/226_fit_split_elf.dts | 67 ++++++ > > tools/binman/test/227_fit_bad_dir.dts | 9 + > > tools/binman/test/228_fit_bad_dir_config.dts | 9 + > > 6 files changed, 598 insertions(+), 10 deletions(-) > > create mode 100644 tools/binman/test/226_fit_split_elf.dts > > create mode 100644 tools/binman/test/227_fit_bad_dir.dts > > create mode 100644 tools/binman/test/228_fit_bad_dir_config.dts > > > > [...] > > > > diff --git a/tools/binman/etype/fit.py b/tools/binman/etype/fit.py > > index 30b20a07a2..63d552ed19 100644> > [...] > > > > @@ -154,6 +159,149 @@ class Entry_fit(Entry_section): > > > > Note that if no devicetree files are provided (with '-a of-list' as above) > > then no nodes will be generated. > > + > > + Generating nodes from an ELF file (split-elf) > > + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > + > > + This uses the node as a template to generate multiple nodes. The following > > + special properties are available: > > + > > + split-elf > > + Split an ELF file into a separate node for each segment. This uses the > > + node as a template to generate multiple nodes. The following special > > + properties are available: > > + > > + fit,load > > + Generates a `load = <...>` property with the load address of the > > + segmnet > > segmnet -> segment, missed it the first time around. > > > + > > + fit,entry > > + Generates a `entry = <...>` property with the entry address of the > > + ELF. This is only produced for the first entry > > + > > + fit,data > > + Generates a `data = <...>` property with the contents of the segment > > + > > + fit,loadables > > + Generates a `loadable = <...>` property with a list of the generated > > + nodes (including all nodes if this operation is used multiple times) > > > > [...] > > > > @@ -363,11 +514,20 @@ class Entry_fit(Entry_section): > > fname = tools.get_input_filename(fdt_fname + '.dtb') > > with fsw.add_node(node_name): > > for pname, prop in node.props.items(): > > - val = prop.bytes.replace( > > - b'NAME', tools.to_bytes(fdt_fname)) > > - val = val.replace( > > - b'SEQ', tools.to_bytes(str(seq + 1))) > > - fsw.property(pname, val) > > + if pname == 'fit,loadables': > > + val = '\0'.join(self._loadables) + '\0' > > + fsw.property('loadables', val.encode('utf-8')) > > + elif pname == 'fit,operation': > > + pass > > + elif pname.startswith('fit,'): > > + self._raise(base_node, node, > > + f"Unknown directive '{pname}'") > > + else: > > + val = prop.bytes.replace( > > + b'NAME', tools.to_bytes(fdt_fname)) > > + val = val.replace( > > + b'SEQ', tools.to_bytes(str(seq + 1))) > > + fsw.property(pname, val) > > I get two distinct "loadables" properties with this config fragment, > and fdtget and mkimage -l only considers the first one: > > @config-SEQ { > description = "NAME.dtb"; > fdt = "fdt-SEQ"; > firmware = "atf-1"; > loadables = "u-boot"; > fit,loadables; > }; Yes that needs fixing, but I'll leave that case for now. It needs its own test. > > $ fdtget simple-bin.fit.fit /configurations/config-1 -p > description > fdt > firmware > loadables > loadables > > $ fdtget simple-bin.fit.fit /configurations/config-1 loadables > u-boot > > $ mkimage -l simple-bin.fit.fit > FIT description: FIT image for U-Boot with bl31 (TF-A) > Created: Thu Feb 24 17:36:36 2022 > Image 0 (u-boot) > Description: U-Boot (64-bit) > Created: Thu Feb 24 17:36:36 2022 > Type: Standalone Program > Compression: uncompressed > Data Size: 727192 Bytes = 710.15 KiB = 0.69 MiB > Architecture: AArch64 > Load Address: 0x00200000 > Entry Point: unavailable > Image 1 (atf-1) > Description: ARM Trusted Firmware > Created: Thu Feb 24 17:36:36 2022 > Type: Firmware > Compression: uncompressed > Data Size: 139342 Bytes = 136.08 KiB = 0.13 MiB > Architecture: AArch64 > OS: ARM Trusted Firmware > Load Address: 0x00040000 > Image 2 (atf-2) > Description: ARM Trusted Firmware > Created: Thu Feb 24 17:36:36 2022 > Type: Firmware > Compression: uncompressed > Data Size: 8024 Bytes = 7.84 KiB = 0.01 MiB > Architecture: AArch64 > OS: ARM Trusted Firmware > Load Address: 0xff3b0000 > Image 3 (atf-3) > Description: ARM Trusted Firmware > Created: Thu Feb 24 17:36:36 2022 > Type: Firmware > Compression: uncompressed > Data Size: 8192 Bytes = 8.00 KiB = 0.01 MiB > Architecture: AArch64 > OS: ARM Trusted Firmware > Load Address: 0xff8c0000 > Image 4 (fdt-1) > Description: fdt-rk3399-gru-bob > Created: Thu Feb 24 17:36:36 2022 > Type: Flat Device Tree > Compression: uncompressed > Data Size: 69392 Bytes = 67.77 KiB = 0.07 MiB > Architecture: Unknown Architecture > Default Configuration: 'config-1' > Configuration 0 (config-1) > Description: rk3399-gru-bob.dtb > Kernel: unavailable > Firmware: atf-1 > FDT: fdt-1 > Loadables: u-boot > > I didn't test if my chromebook_kevin boots in this double-loadables > configuration, though. I wish we could get the kevin patches applied. What on earth is going on there? I haven't been able to test any of this on kevin. [..] Regards, Simon