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 1D65EC433EF for ; Sun, 6 Mar 2022 03:09:38 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 1EEF583C4D; Sun, 6 Mar 2022 04:08:51 +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="CLo1TQOw"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id A9D9683CA0; Sun, 6 Mar 2022 04:08:38 +0100 (CET) Received: from mail-oo1-xc35.google.com (mail-oo1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (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 EFB8B83BDC for ; Sun, 6 Mar 2022 04:08:26 +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-oo1-xc35.google.com with SMTP id i6-20020a4ac506000000b0031c5ac6c078so13864168ooq.6 for ; Sat, 05 Mar 2022 19:08:26 -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=/SEef/NXzbVBU6a8hT3Rp4Sds58nBMLJWse7DulZpLs=; b=CLo1TQOwN0JAt/ARZ1v0MSftlUKYzu6DvuoJEcvZjKUqA4hytvlb8nUMsfknrAc6Eh 0sG4hXDChxQK1CFl8HB1zMscNbMotpZbugAmX6JcQIc8NUCAx+zS3xotwOrPoQpBk8io yJt6p5SNK2P7y7G74DWRlZXlvwJF/YDANq3RY= 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=/SEef/NXzbVBU6a8hT3Rp4Sds58nBMLJWse7DulZpLs=; b=1HB4VgHH4dGeRvzY5BBG2n0wnyU81UlBySRoPX6Y1YS11dOYR+26ocZI0PwTskNhv9 2HILXO0HA1mybYiXgaHzu18+ckY6Ut7my01URVGCh2WYb6+Jd/G+njbcBC8iy2laq5ed u6u9nTr11f9prQtqvIMlHNTr+BJ+jN3XqUIfVxn7gtzP0gIc7EiIzjZWO2iOfgSGKSOz Z1mrNb8X21NF+nBQB0ADZMiVyIzZ0zTYSabcp0yQv402Q/P4emKggyr80762fLiwZ8y+ iOEq+qiUxG40Fbx1oG+7GH1K7RqpEqK6F4U7SIZ+s1pWEHKnUtpu0MyjHd/sESq32rzY 44Zw== X-Gm-Message-State: AOAM531npkkDl5THw/hVLUShJ5m07eLAqpfZrb8jAxNPbe1PFQhzwnFu ltB+vmFd6EIpe+enlQQWIdYP0/fbab/VTa8nlwwYtQ== X-Google-Smtp-Source: ABdhPJyC1tUZRbio+3+Q+tgIpD6RUNnpk/1xXfCvXwLLFVVIuTHThatCBglrRLFxjWbxrkiGd1rhDROy2oIOoepieA0= X-Received: by 2002:a05:6870:14cf:b0:d9:a9ce:92a9 with SMTP id l15-20020a05687014cf00b000d9a9ce92a9mr2721045oab.64.1646536105220; Sat, 05 Mar 2022 19:08:25 -0800 (PST) MIME-Version: 1.0 References: <20220223230040.159317-1-sjg@chromium.org> <20220223230040.159317-20-sjg@chromium.org> <6d32aa01-9940-c112-af3e-b0fd9c39652d@gmail.com> In-Reply-To: <6d32aa01-9940-c112-af3e-b0fd9c39652d@gmail.com> From: Simon Glass Date: Sat, 5 Mar 2022 20:08:12 -0700 Message-ID: Subject: Re: [PATCH v2 19/25] binman: Keep a separate list of entries for fit 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: > > The current implementation sets up the FIT entries but then deletes the > > 'generator' ones so they don't appear in the final image. > > They still show up in the fdtmap if I add one to rockchip-u-boot.dtsi: > > $ binman ls -i u-boot-rockchip.bin > Name Image-pos Size Entry-type Offset > ------------------------------------------------------------- > main-section 0 103520 section 0 > mkimage 0 1a000 mkimage 0 > fit 1a000 e8d74 fit 1a000 > u-boot 1a644 b1898 section 644 > u-boot-nodtb 1a644 b1898 u-boot-nodtb 0 > @atf-SEQ 0 0 section 0 > atf-bl31 0 0 atf-bl31 0 > @tee-SEQ 0 0 section 0 > tee-os 0 0 tee-os 0 > @fdt-SEQ 0 0 section 0 > fdtmap 102d74 79c fdtmap 102d74 > > But not simple-bin.map: > > ImagePos Offset Size Name > 00000000 00000000 00103520 main-section > 00000000 00000000 0001a000 mkimage > 0001a000 0001a000 000e8d74 fit > 0001a644 00000644 000b1898 u-boot > 0001a644 00000000 000b1898 u-boot-nodtb > 00102d74 00102d74 0000079c fdtmap > > This happens in v1 as well, but I hadn't checked it then. > > (The "fit" size and "fdtmap" offset are off by 0x10 too, but I'm not > sure why yet.) Well let's fix this after the series. We need tests for the map and so on. > > > This is a bit clumsy. We cannot build the image more than once, since the > > generator entries are lost during the first build. Binman requires that > > calling BuildSectionData() multiple times returns a valid result each > > time. > > I think the generator entries should be turned into concrete entries and > be removed in _gen_entries(), so BuildSectionData() should work on the > entries that were generated. This way the individual entries would show > up in fdtmap and could be binman-extracted/replaced as well. That makes sense, but I'm not sure how to implement it. The split-elf thing needs the contents of the entries which is not available at the start. It is likely available before BuildSectionData() is called, but not necessarily. So the template needs to hang around at least as long as that. I think there is something we could do here, but it isn't quite clear to me. Perhaps we need a expand-nodes-based-on-contents phase in control.py ? Eek... > > For FDTs we can generate blob entries for each file, for ELFs maybe we > can split them into files like the script used to do (bl31_0x.bin) > and do the same? I'm not a big fan of adding files. Binman should be able to hold everything in memory. It does generate files for later inspection though, so yes we could add this feature. > > Maybe some new entry types, "data" for arbitrary data unrelated to a > file whose contents we can set, or "elf-segment" that can extract a > segment from an ELF file (but I don't like the information loss there). Yes I quite like the idea of new entry types. In fact I was hoping to turn split-elf into an entry type (one that generated multiple entries). But I decided to stop before doing that since we really need to gets the code in there, fix the bugs /move forward with some of the ideas you and others have. > > > Keep a separate, private list which includes the generator nodes and use > > that where needed, to correct this problem. Ensure that the missing list > > includes removed generator entries too. > > > > Signed-off-by: Simon Glass > > --- > > > > (no changes since v1) > > I'm more and more convinced that generator nodes needs a thorough > redesign, but the patch is consistent with status quo, so: > > Reviewed-by: Alper Nebi Yasak > > > tools/binman/etype/fit.py | 33 ++++++++++++++++++++++++++++----- > > 1 file changed, 28 insertions(+), 5 deletions(-) > > > > diff --git a/tools/binman/etype/fit.py b/tools/binman/etype/fit.py > > index e1b056f56e..30b20a07a2 100644 > > --- a/tools/binman/etype/fit.py > > +++ b/tools/binman/etype/fit.py > > @@ -163,10 +163,15 @@ class Entry_fit(Entry_section): > > key: relative path to entry Node (from the base of the FIT) > > value: Entry_section object comprising the contents of this > > node > > + _priv_entries: Internal copy of _entries which includes 'generator' > > + entries which are used to create the FIT, but should not be > > + processed as real entries. This is set up once we have the > > + entries > > Maybe this could be "_templates" or "_entry_generators" and only keep > track of the generator entries. Again I think we can revisit that. I feel it is a bit messy right now, too. > > > """ > > super().__init__(section, etype, node) > > self._fit = None > > self._fit_props = {} > > + self._priv_entries = {} > > > > for pname, prop in self._node.props.items(): > > if pname.startswith('fit,'): > > > > [...] Regards, Simon