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 96EF4C433F5 for ; Thu, 10 Mar 2022 19:36:52 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 6E03583AFA; Thu, 10 Mar 2022 20:36:50 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="Zn9ufE9S"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id C709883AE9; Thu, 10 Mar 2022 20:36:33 +0100 (CET) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 77C7E83AE1 for ; Thu, 10 Mar 2022 20:36:28 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=alpernebiyasak@gmail.com Received: by mail-ed1-x534.google.com with SMTP id w4so8313314edc.7 for ; Thu, 10 Mar 2022 11:36:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:from:subject:to:cc :references:content-language:in-reply-to:content-transfer-encoding; bh=YXl/1b+TGx9mFOthpz4wa4GaTWKDMcNRkXaCk0gM1dc=; b=Zn9ufE9S1do6E3Evx5bukEDSIfo9yNl4DinjHVSQ7vfQurYP0kEmk6FawMztxHl4Rf QwWmTr56gKTAT03pX/eAvruvI8/gyZ6JpvVZJFj7HoiqjoiqpqACWRC6cBS8Nb7/qFym dGy5DY0xpSNkfH3/7ESI6X9b9Gxg6IB0Av8ZhabKu5+8pMAk6Hv49y1I8bIAyqfgTP9M j9SeD22+8z7abMKrqA4w/z6nEbInzbM2dWg/3lPbw/icchZ6ipBy6IAxsOkWcI/R/szC n+iXKX8444URrrfyM+OgqOVhnfN+uzWeQV8jYf2zLGqccrvquMpTJVq8bI+/yxRpb/T+ 9cRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:from :subject:to:cc:references:content-language:in-reply-to :content-transfer-encoding; bh=YXl/1b+TGx9mFOthpz4wa4GaTWKDMcNRkXaCk0gM1dc=; b=5RuJot9KqK5YPE16n1ixcKOKU7rer49zGykxj8x58khdCT0Pg4TJFg51d0xmuWGuwv zU51rdYg69+CHF1iOIvSKZ9kZX0xCOuVcW68rIwscBB7743RpsZxP/sni2R3JxS5u9Oj ZSHHh/afHvvOaKkBiMQHcwZ3ObvJgJkGhUiB5ixj3I1qcYc02BmmbthY/YGUZyZ6yr6K Ohju52Cx62nQkFCAmN9yNpYUMzM4jdvMK0NcgH6E2Zt/iHU0fpCAi35bnDUNDZpMKDH9 0/hBVR3DqxaYAiJwysT+j3D7gAY6Aw0quV4kGOUN41RK254twR+M+eexjVzrU7W++/nR 9LxA== X-Gm-Message-State: AOAM530Hb2NVk4vejvUTwZZc0bM0lAOPOjmv2ZimD+l63Chi1husKtGO Hge6NJfMKCyjjRp95hvCkLI= X-Google-Smtp-Source: ABdhPJz6apqYCEEGBoYDKWpw6TLp1Z9wAnUaIeavhn+61bsw14a7UmWVdRQxjZnUGZbtCKrxQid4pQ== X-Received: by 2002:aa7:d708:0:b0:416:67d:5e07 with SMTP id t8-20020aa7d708000000b00416067d5e07mr6081195edq.166.1646940988083; Thu, 10 Mar 2022 11:36:28 -0800 (PST) Received: from [192.168.0.74] ([178.233.26.119]) by smtp.gmail.com with ESMTPSA id f7-20020a17090631c700b006b293ddbca1sm2096988ejf.35.2022.03.10.11.36.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Mar 2022 11:36:27 -0800 (PST) Message-ID: <08f24b2a-e2fb-8f61-e158-a5fa313ad231@gmail.com> Date: Thu, 10 Mar 2022 22:30:21 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 From: Alper Nebi Yasak Subject: Re: [PATCH v2 19/25] binman: Keep a separate list of entries for fit To: Simon Glass Cc: Ivan Mikhaylov , Tom Rini , Philippe Reynes , huang lin , Jeffy Chen , Kever Yang , U-Boot Mailing List References: <20220223230040.159317-1-sjg@chromium.org> <20220223230040.159317-20-sjg@chromium.org> <6d32aa01-9940-c112-af3e-b0fd9c39652d@gmail.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 On 06/03/2022 06:08, Simon Glass wrote: > On Thu, 3 Mar 2022 at 14:17, Alper Nebi Yasak wrote: >>> 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... I can't think of anything proper. I guess it could need architectural changes, but I need to read more of the code and get a better grasp of things. >> >> 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. After this and the other fixes and such, I hope I can set aside some time and experiment more on the ideas I've been throwing at you. Sorry if I ended up delaying this too much already...