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 39F39C00140 for ; Tue, 2 Aug 2022 08:19:49 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id C9F7C83FB0; Tue, 2 Aug 2022 10:19:47 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=tinet.cat Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id 45F5E83E4C; Tue, 2 Aug 2022 10:19:46 +0200 (CEST) Received: from mx1.tinet.cat (mx1.tinet.cat [195.77.216.146]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 7A14081DAB for ; Tue, 2 Aug 2022 10:19:43 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=tinet.cat Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=xdrudis@tinet.cat X-ASG-Debug-ID: 1659428381-163e7b47621793c0001-4l7tJC Received: from smtp01.tinet.cat (smtp.tinet.cat [195.77.216.131]) by mx1.tinet.cat with ESMTP id MZXCY7vPBFOboNdf; Tue, 02 Aug 2022 10:19:41 +0200 (CEST) X-Barracuda-Envelope-From: xdrudis@tinet.cat X-Barracuda-Effective-Source-IP: smtp.tinet.cat[195.77.216.131] X-Barracuda-Apparent-Source-IP: 195.77.216.131 Received: from begut (99.red-79-152-185.dynamicip.rima-tde.net [79.152.185.99]) by smtp01.tinet.cat (Postfix) with ESMTPSA id B2E84605D0AC; Tue, 2 Aug 2022 10:19:41 +0200 (CEST) Date: Tue, 2 Aug 2022 10:19:25 +0200 From: Xavier Drudis Ferran To: Simon Glass Cc: Quentin Schulz , Xavier Drudis Ferran , Quentin Schulz , Kever Yang , Andy Yan , Lin Huang , =?utf-8?B?6ZmI5YGl5rSq?= , Manivannan Sadhasivam , Nick Xie , Johan Jonker , deepakdas.linux@gmail.com, linux@alxd.me, U-Boot Mailing List Subject: Re: [SPAM] Re: Replace make-fit-atf.py with binman. Was: migrate u-boot-rockchip.bin to binman and generate an image for SPI Message-ID: X-ASG-Orig-Subj: Re: [SPAM] Re: Replace make-fit-atf.py with binman. Was: migrate u-boot-rockchip.bin to binman and generate an image for SPI References: <20220725172953.GD2029@begut> <20220725173333.GE2029@begut> <1c18731d-304b-aa76-6c2d-334398cdc4f1@theobroma-systems.com> <702c542e-ccbf-4fc4-3584-744d701d3fe1@theobroma-systems.com> <0cf17174-8507-63e0-151e-84a2bc99f4d7@theobroma-systems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Barracuda-Connect: smtp.tinet.cat[195.77.216.131] X-Barracuda-Start-Time: 1659428381 X-Barracuda-URL: https://webmail.tinet.cat:443/cgi-mod/mark.cgi X-Barracuda-Scan-Msg-Size: 3205 X-Barracuda-BRTS-Status: 1 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5036 1.0000 0.7500 X-Barracuda-Spam-Score: 0.75 X-Barracuda-Spam-Status: No, SCORE=0.75 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=6.0 KILL_LEVEL=8.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.99793 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 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 El Mon, Aug 01, 2022 at 01:13:27PM -0600, Simon Glass deia: > > > > Am I completely lost or does what I want to do make some kind of sense? > > Well I still feel that we should handle this properly in binman. > I respect your feelings but would you care explaining the goal of binman? I first thought it was about handling binaries (things like copy binary content, aligning it, padding, extracting and selecting parts from one binary to form the final image...). A little like a linker but for other kinds of binary files, with maybe headers but no symbol resolution and all. Maybe more like GNU ar but for images instead of executables. But then you seem to say it should handle dependencies between build files and be called only once ? So should it eventually become a sort of make itself ? > I don't even think we need to allow images to be incorporated in other > images. We can probably just allow a section to have a filename, a bit > like this patch [1]. > There's a image r-sd and an image r-spi. Both need to have inside the same binary itb, packed differently. If r-sd has a section with itb and writes that section to a file, r-spi still needs to incorporate that section as a binary, and to do that it needs to know the other image has already written its section to a file or built into somewhere in memory. So there're dependencies, and synchronisation if you want to built images in parallel. make can handle that if you call binman multiple times. But if you don't want that, then you need to either include dependency management into binman (turning it into a little make working from dts subtrees instead of makefiles) or forbid that binaries used by binman could be images produced by binman, and then you need other binary manipulation tools (like make_fit_atf.py, which is basically what you have now, but that's apparently not desired either). If it was just me who feels lost, then it'd be just that I don't get it, but Quentin is saying something similar. In any case, don't forget what Jerome said about tee.bin needing different parsing than split-elf does in binman. The sections of tee.bin can also end up in u-boot.itb. Adding that to binman would maybe make more sense that what I was trying to add, in the sense that binman be a swiss army knive of parsing and building binaries. But then you'd still have the problem that if images built by binman cannot be incorporated in images built by binman, then something else has to build u-boot.itb. And that something else is currently make_fit_atf.py and works fine, so why the trouble ? We're kind of running in circles, and for me it would be helpful to understand the goal and scope of binman to understand what would be desirable, because the status quo seems preferable to some kind of feature creep in binman that I can't seem to reconcile with the philosophy of one tool doing one task and well. Maybe most people here already understand all this, but sometimes explaining the basics to a foreign bystander who knows little of the subject (hello, that's me) can help people sort out thoughts? Thanks, and sorry for the wall of text.