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 DCA4EC4332F for ; Mon, 7 Nov 2022 17:33:35 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id BE60384FAC; Mon, 7 Nov 2022 18:33:23 +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="RHwnp7lN"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 85D8585035; Mon, 7 Nov 2022 18:33:21 +0100 (CET) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 63D1A84F66 for ; Mon, 7 Nov 2022 18:33:18 +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-ej1-x633.google.com with SMTP id y14so32079661ejd.9 for ; Mon, 07 Nov 2022 09:33:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=pq074MZupM4nXQ6S8FmnloYkwxvGMEYGm59vR0nf1YY=; b=RHwnp7lNoVtRdyVnPvS2BWhRp8NDxUSOUedCvrHA3jTamwCoJsw6Iwuv8LuHHDkQ6c sXVsJ630pvGrsyZBz5aC70wwzpvgujQE9GdB+4kIA34jYoINub++Nr6AotdKCEspdiQu h3H4Wk90UBdGVT76KgmAVdDZhKkHxUhy/dEfI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=pq074MZupM4nXQ6S8FmnloYkwxvGMEYGm59vR0nf1YY=; b=CQCGs8YGjhwb/AKMyLGGqxYf9bMUep+WRfIEwz76nO6zBMvYeW2hckRi2vhxPLT3q2 Q9WIxAH5GDeFLMlx2CyV7uBrwwVv1h6AiVTVQuOdas8XJuH4CAu+ZZCWUe1sa/sJs5PG ZZFydM003WD6oYjRnz3B5266+FX2N7wuszwEpgm3Wi1XBNcyPxnvRTOwy5fl/6SANOlX jDEcLLYCtd6GdD/iZEzx9fLM7gxUUZPzFJIZQoyb5RPaJ84jLr8bdMFcMaXgGcsHLabk TdUFxs2ArYH3UHk37WR2MXGGrtGFvkY4PVQTWJfyjeYdPQALZqU2AdQisQ19bsUpbds4 TItQ== X-Gm-Message-State: ACrzQf2gWOVZzMmbsmXsWkjdGEOepdABhdhXg52lE8bgtC1yHInUQwoy Lc1daqPy13wcXH88eHlXe5yvwcQFYCFPQm0gXx8tqw== X-Google-Smtp-Source: AMsMyM6PEV+Jnah8n96tSsCVpfWclH7Ys+YpW4EMPTtVlVV/+WNCOjtJ1l0bVUUJQZXpSav1113BQoM6i8GWEY40FQE= X-Received: by 2002:a17:906:da86:b0:740:7120:c6e6 with SMTP id xh6-20020a170906da8600b007407120c6e6mr48576919ejb.44.1667842397570; Mon, 07 Nov 2022 09:33:17 -0800 (PST) MIME-Version: 1.0 References: <20221106224011.606743-1-sjg@chromium.org> <20221106224011.606743-2-sjg@chromium.org> In-Reply-To: From: Simon Glass Date: Mon, 7 Nov 2022 10:33:06 -0700 Message-ID: Subject: Re: [PATCH v4 1/7] binman: Allow writing section contents to a file To: quentin.schulz@theobroma-systems.com Cc: U-Boot Mailing List , Roger Quadros , Alper Nebi Yasak , Peter Geis , Philippe Reynes , Ivan Mikhaylov , Tom Rini , huang lin , Jeffy Chen , Kever Yang , Philipp Tomsich , Heiko Thiery , Stefan Herbrechtsmeier 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.6 at phobos.denx.de X-Virus-Status: Clean Hi Quentin, On Mon, 7 Nov 2022 at 08:36, wrote: > > Hi Simon, > > On 11/7/22 4:28 PM, Simon Glass wrote: > > Hi Quentin, > > > > On Mon, 7 Nov 2022 at 07:25, Quentin Schulz > > wrote: > > > > > > Hi Simon, > > > > > > On 11/6/22 23:40, Simon Glass wrote: > > >> At present only the image (which is a section) has a filename. Move this > > >> implementation to the entry_Section class so that any section can have a > > >> filename. With this, the section data is written to a file. > > >> > > >> This allows parts of an image to be written, along with the entire image. > > >> > > >> Signed-off-by: Simon Glass > > >> --- > > >> > > >> (no changes since v1) > > >> > > >> tools/binman/binman.rst | 5 +++++ > > >> tools/binman/etype/section.py | 12 +++++++++- > > >> tools/binman/ftest.py | 14 ++++++++++++ > > >> tools/binman/image.py | 3 --- > > >> tools/binman/test/261_section_fname.dts | 29 +++++++++++++++++++++++++ > > >> 5 files changed, 59 insertions(+), 4 deletions(-) > > >> create mode 100644 tools/binman/test/261_section_fname.dts > > >> > > >> diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst > > >> index fda16f1992d..79578ff127b 100644 > > >> --- a/tools/binman/binman.rst > > >> +++ b/tools/binman/binman.rst > > >> @@ -837,6 +837,11 @@ name-prefix: > > >> renamed to 'ro-u-boot' and 'rw-u-boot'. This can be useful to > > >> distinguish binaries with otherwise identical names. > > >> > > >> +filename: > > >> + This allows the contents of the section to be written to a file in the > > >> + output directory. This can sometimes be useful to use the data in one > > >> + section in different image, since there is currently no way to share data > > >> + beteen images other than through files. > > >> > > > > > > IIRC, this is currently incorrect until we have inter-image dependencies > > > since binman is building images in parallel by default. Suggesting this > > > is a possible use-case is at beast misleading. For me, this is only > > > useful for archiving embedded binaries, e.g. what we did for > > > idbloader.img for Rockchip lately (which is "needed" only to keep the > > > 3rd party tutorials/documentation not outdated). > > > > > > Maybe I missed some recent development that fixes this, lemme know if > > > that's the case or if my assumptions are wrong. > > > > Images themselves are built one after the other, so far as I know: > > > > for image in images.values(): > > invalid |= ProcessImage(image, args.update_fdt, args.map, > > allow_missing=args.allow_missing, > > allow_fake_blobs=args.fake_ext_blobs) > > > > WIthin each image Binman tries to build everything in parallel if > > possible, but it is currently possible to use the outputs of one image > > in a subsequent one. > > > > That seems right indeed. ProcessImage uses OrderedDict internally. Just need to trust that the parsing of the DTB is reproducible too but I guess that's fine. > > This also explains why you didn't change the u-boot-rockchip-spi.bin image generation I complained about in another review. > > I'm a bit scared that implicitly relying images being sequentially created is not going to bite us back in the future once/if we do parallel building of images. Yes, we probably will want parallel images at some point but we'll need to support collections that include things from other images. > > I guess this is fine then :) OK. Regards, Simon