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 5A8B3C4332F for ; Mon, 7 Nov 2022 15:28:53 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 539C484F5D; Mon, 7 Nov 2022 16:28: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="RAP8pQrL"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 9CB9584F3C; Mon, 7 Nov 2022 16:28:50 +0100 (CET) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (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 0738984F57 for ; Mon, 7 Nov 2022 16:28:48 +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-x629.google.com with SMTP id d26so31041012eje.10 for ; Mon, 07 Nov 2022 07:28:48 -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=IAjpe9R4GhnYT7tCaAzvdl0xqCe4DCcZONWiZj6hL6c=; b=RAP8pQrLh8EL4zYddMyXOTKRvDprZH1QaYGe5fTNLbEdZKP2Oi0QxEnWT7t8lE9TsW 6KcL7Fe+wyn5zE6+lGkNGlhUSHbF8jiLXF91yAKVOBtJ7Q+7OhWpFwGA8rdBujy/eES+ SEqA1wevbSQjnVs5ZMK8qYO9e6aCjwRBL1/y8= 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=IAjpe9R4GhnYT7tCaAzvdl0xqCe4DCcZONWiZj6hL6c=; b=iHJG/i+ODde/npvHQo57PA/vgBzhLo9SYv8RMSU1G004jq7hzFJyZ1Iuzy3n5uYlhI lW91X/2hZovxijA1clPoz9+SwwZrPJYlxbuSYqtDQxV5dEAqg0H/Z0P8iZeItpTvXVuB E2RodFrLT33LrmJ0Jm/fayN3ZIZVes2JIhVXJF1KJD8fCbbXLGHxmkx9GxqpQL9NNfHB +iXTJcsTC/tUQl+BwPiVfjdxCCqR7Ay5wSc7W66m+Q+IF7COcNXMcCKBnhqViqSeJL9I A/PI3B6rnlBv5MERYagUINAdNPi0gFzdv48iAjf2MXqX2hREREerU8EfFu1RMnEL5xvK 7n1w== X-Gm-Message-State: ACrzQf1Vqex6AhA/xDZjU5UdL/d0oKlQKAkdKQYEoH9YsPfEdt6yP2ec phzl2Ma0TtVJvBETElGZ3PkfuDqjx6a4A6SFOOXT96tUUpAXSw== X-Google-Smtp-Source: AMsMyM5zuj93ZMQn2gfhrJxltW+NLv6MjmJegpx/TV++Z6yqcPai0abdS36FwboXbs1tfa2CV4lMOBGriD0SgfH+p04= X-Received: by 2002:a17:906:da86:b0:740:7120:c6e6 with SMTP id xh6-20020a170906da8600b007407120c6e6mr48097227ejb.44.1667834927293; Mon, 07 Nov 2022 07:28:47 -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 08:28:35 -0700 Message-ID: Subject: Re: [PATCH v4 1/7] binman: Allow writing section contents to a file To: Quentin Schulz 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 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. I know it would be better to allow cross-image collections, etc. but that is not implemented at present. Regards, SImon