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 460DFC19F28 for ; Wed, 3 Aug 2022 11:28:12 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 5A16084522; Wed, 3 Aug 2022 13:28:10 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org 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=kernel.org header.i=@kernel.org header.b="X8MSUt48"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 94F03828FD; Wed, 3 Aug 2022 13:28:08 +0200 (CEST) Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id C509080756 for ; Wed, 3 Aug 2022 13:28:05 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=pali@kernel.org Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 7AB9AB819FC; Wed, 3 Aug 2022 11:28:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E42E5C433C1; Wed, 3 Aug 2022 11:28:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1659526084; bh=FIVckx1XLKWx1mMZHXsCDSnI9lUdGws1anL+tP2kits=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=X8MSUt48zLma9VsCdlIqooOQvqFlg/zQ6pL06Mxj3EhjXfNxzsXEoKJEc/oMZvazO H6axKXGCD0YqKg14cBnDqd5uxaCJW7+RkYw9xbHoPBOyzo3ErywSwhFTagy378NvvH ekmcZl1lU0N1Zbag9UYcoyTysJN0uV3sBA2SpSeUsctIyq5XZOasl2rqn3oio/iuBe cIe3/xk2+a/R9+pZuyUFk6s+GjfSy1wLtErSi19JUHlXAsfChNqifZc6PTT8jrEn8e 4cMtAsq/rGFHUrPGB3GfkfHVV+56XZNlj3xGOmD2u+TfNNk7C3T03t2hYZKjWSXXX1 4MKX3Z0iFa/IQ== Received: by pali.im (Postfix) id 5D92182E; Wed, 3 Aug 2022 13:28:01 +0200 (CEST) Date: Wed, 3 Aug 2022 13:28:01 +0200 From: Pali =?utf-8?B?Um9ow6Fy?= To: Tom Rini Cc: Simon Glass , U-Boot Mailing List Subject: Re: [PATCH 2/2] Makefile: Build final mpc85xx non-SPL image in standard file u-boot.bin Message-ID: <20220803112801.6edejzme3lrsu77k@pali> References: <20220801154220.20068-1-pali@kernel.org> <20220801154220.20068-2-pali@kernel.org> <20220801193900.zpbunhwopisefjjh@pali> <20220801231546.GY1146598@bill-the-cat> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220801231546.GY1146598@bill-the-cat> User-Agent: NeoMutt/20180716 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 On Monday 01 August 2022 19:15:46 Tom Rini wrote: > On Mon, Aug 01, 2022 at 09:39:00PM +0200, Pali Rohár wrote: > > On Monday 01 August 2022 13:13:22 Simon Glass wrote: > > > Hi Pali, > > > > > > On Mon, 1 Aug 2022 at 09:43, Pali Rohár wrote: > > > > > > > > Currently Makefile produces final mpc85xx image when SPL is not used in > > > > custom file u-boot-with-dtb.bin. It is quite confusing name as build > > > > process produce also intermediate file standard file u-boot-dtb.bin (which > > > > is just intermediate and not bootable). Other platforms use u-boot.bin > > > > (UBOOT_BIN) as standard name for final bootable raw image. > > > > > > > > So change Makefile rules and binman to produce final bootable file for > > > > mpc85xx also into file u-boot.bin. There is just need for mpc85xx to not > > > > define default rule for u-boot.bin then instruct binman (via DTS file) to > > > > store final image into u-boot.bin (instead of u-boot-with-dtb.bin) and > > > > finally rename target u-boot-with-dtb.bin to u-boot.bin. > > > > > > > > With this change are also removed custom Makefile hacks for mpc85xx that it > > > > produced non-standard output file. And also updated documentation. > > > > > > > > Signed-off-by: Pali Rohár > > > > --- > > > > Makefile | 19 +++++-------------- > > > > arch/powerpc/dts/kmcent2-u-boot.dtsi | 2 +- > > > > arch/powerpc/dts/u-boot.dtsi | 2 +- > > > > board/freescale/p1_p2_rdb_pc/README | 2 +- > > > > board/freescale/p2041rdb/README | 3 --- > > > > board/freescale/t102xrdb/README | 2 +- > > > > board/freescale/t104xrdb/README | 2 +- > > > > board/freescale/t208xqds/README | 2 +- > > > > board/freescale/t208xrdb/README | 2 +- > > > > 9 files changed, 12 insertions(+), 24 deletions(-) > > > > > > At present u-boot.bin has a very standard meaning - it is U-Boot with the DT. > > > > > > Boards which need something more than that can/should use binman to > > > create a separate file. > > > > > > I certainly agree that u-boot-with-dtb.bin is a terrible name, though. > > > Something more descriptive would be better. > > > > > > But is it possible to drop these SoC-specific rules in the Makefile > > > and just build everything needed in the standard binman rule in the > > > Makefile? > > > > > > Regards, > > > Simon > > > > I do not know what is binman doing and how to use it. I just do not see > > reason why it is needed to use such additional tool for building final > > binary for powerpc/mpc85xx as other arm boards do not use it at all. > > > > Ad your comment "At present u-boot.bin has a very standard meaning - it > > is U-Boot with the DT." - This is exactly what binman for mpc85xx > > produces. > > > > So I see there could be improvements, but as a first step this my patch > > should be enough? > > So, one of the issues with PowerPC stuff is that much of it is so far > behind the rest of U-Boot in terms of frameworks. So yes, let us start > by fixing the functional problem you're describing here and then see > what appetite exists for further work here. > > -- > Tom Ok, so these two patches in this patch series is a starting point. Now I send another patch which does another cleanup in this area: https://patchwork.ozlabs.org/project/uboot/patch/20220803112442.4735-1-pali@kernel.org/